Re: [openstack-dev] [nova] live-snapshot/cloning of virtual machines

2013-08-19 Thread Shawn Hartsock 
For what it's worth... this doesn't seem too bad to me...

I was planning on using this part of the vSphere API:
* 
https://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/vim.vm.CloneSpec.html

...to accomplish the clone part of the BP. The API contains a "spec" section 
where you tell the ESX hypervisor how to handle things like network identity...
* 
https://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/vim.vm.customization.IPSettings.html

... I was going to use this to plumb together the "live-snapshot" bit ...
* 
https://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/vim.VirtualMachine.html#createSnapshot

... which includes stuff about how to handle memory.

So, I didn't read this blueprint as especially hard to accomplish in the 
vmwareapi driver. It just would eat more time than I have right now and would 
require a deeper level of understanding of how the vSphere hypervisor suite 
works than most of the other features currently use. I'm fully planning on 
playing with this in IceHouse just to see how it would go, it's probably one of 
the more nifty new features we could add.

Note: these are old features for the API and they are a tad complicated, but 
it's all well within the realm of supported! In fact, it's standard operating 
procedure to use the clone feature to scale-out an application in some vSphere 
shops. (albeit, in production the admins I know personally, use clone with 
power-off from a 'template' and the system comes up with a new MAC/etc on first 
boot... cloning from a running system is possible, but I would recommend 
cloning from a power-off state unless you've got a hot-plug feature in your 
guest OS)



# Shawn Hartsock

- Original Message -
> From: "Daniel P. Berrange" 
> To: "OpenStack Development Mailing List" 
> Sent: Monday, August 19, 2013 5:24:59 AM
> Subject: Re: [openstack-dev] [nova] live-snapshot/cloning of virtual machines
> 
> On Mon, Aug 19, 2013 at 08:28:58AM +1200, Robert Collins wrote:
> > On 17 August 2013 07:01, Russell Bryant  wrote:
> > 
> > >> Maybe we've grown up to the point where we have to be more careful and
> > >> not introduce
> > >> these kind of features and the maintenance cost of introducing
> > >> experimental features is
> > >> too great. If that is the community consensus, then I'm happy keep the
> > >> live snapshot stuff
> > >> in a branch on github for people to experiment with.
> > >
> > > My feeling after following this discussion is that it's probably best to
> > > keep baking in another branch (github or whatever).  The biggest reason
> > > is because of the last comment quoted from Daniel Berrange above.  I
> > > feel that like that is a pretty big deal.
> > 
> > So, reading between the lines here, I guess you're worried that we'd
> > let code paths that violate what upstream will support leak into the
> > main codepaths for libvirt - and thus we'd end up with a situation
> > where we aren't supported by upstream for all regular operations.
> 
> Yes, if you perform a live clone of a VM, then you have effectively
> tainted that VM for the rest of its lifetime. From the virt host
> vendors' POV, any unexpected or problematic behaviour you get from
> that VM thereafter will be outside scope of support. The onus would
> be on the openstack sysadmin to demonstrate that the same problem
> occurs without the use of live cloning.
> 
> Running a production cloud using a feature that your virt host
> vendor considers unsupported would be somewhat reckless IMHO, unless
> you think your sysadmins think they have the skills to solve all
> possible problems in that area themselves, which is unlikely for most
> cloud vendors.
> 
> 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 :|
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] live-snapshot/cloning of virtual machines

2013-08-19 Thread Daniel P. Berrange 
On Mon, Aug 19, 2013 at 01:28:25AM -0700, Tim Smith wrote:
> On Sun, Aug 18, 2013 at 1:28 PM, Robert Collins
> wrote:
> 
> > On 17 August 2013 07:01, Russell Bryant  wrote:
> >
> > >> Maybe we've grown up to the point where we have to be more careful and
> > >> not introduce
> > >> these kind of features and the maintenance cost of introducing
> > >> experimental features is
> > >> too great. If that is the community consensus, then I'm happy keep the
> > >> live snapshot stuff
> > >> in a branch on github for people to experiment with.
> > >
> > > My feeling after following this discussion is that it's probably best to
> > > keep baking in another branch (github or whatever).  The biggest reason
> > > is because of the last comment quoted from Daniel Berrange above.  I
> > > feel that like that is a pretty big deal.
> >
> > So, reading between the lines here, I guess you're worried that we'd
> > let code paths that violate what upstream will support leak into the
> > main codepaths for libvirt - and thus we'd end up with a situation
> > where we aren't supported by upstream for all regular operations.
> >
> > I agree that *that* is a big deal : is there something we could do to
> > prevent that happening? E.g. annotating this whole thing as
> > experimental/not upstream supported or something?
> >
> 
> My understanding is that the live-snapshot extensions are to be disabled by
> default (either on the driver side or the API side) and must be explicitly
> enabled via a nova configuration change. Thus, it is not interferant with
> mainline codepaths by default, and the user will not place themself into an
> "unmaintainable" position unless they or their OpenStack distro provider
> flips that particular switch.
>
> That would seem to me a sufficiently high bar for preventing the user from
> shooting themselves in the foot. As for any objections to the mere
> _existence_ of the live-snapshot capability, I propose that the market
> answer the question as to whether or not the feature has value.

NB live-snapshots are fine if used for rollback/forward of an individual
VMs. It is only use of live snapshots for the purpose of cloning VMs
that's the issue here. Whether the market wants live cloning or not is
irrelevant until a vendor will actually support it from a technology POV

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 :|

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] live-snapshot/cloning of virtual machines

2013-08-19 Thread Daniel P. Berrange 
On Mon, Aug 19, 2013 at 08:28:58AM +1200, Robert Collins wrote:
> On 17 August 2013 07:01, Russell Bryant  wrote:
> 
> >> Maybe we've grown up to the point where we have to be more careful and
> >> not introduce
> >> these kind of features and the maintenance cost of introducing
> >> experimental features is
> >> too great. If that is the community consensus, then I'm happy keep the
> >> live snapshot stuff
> >> in a branch on github for people to experiment with.
> >
> > My feeling after following this discussion is that it's probably best to
> > keep baking in another branch (github or whatever).  The biggest reason
> > is because of the last comment quoted from Daniel Berrange above.  I
> > feel that like that is a pretty big deal.
> 
> So, reading between the lines here, I guess you're worried that we'd
> let code paths that violate what upstream will support leak into the
> main codepaths for libvirt - and thus we'd end up with a situation
> where we aren't supported by upstream for all regular operations.

Yes, if you perform a live clone of a VM, then you have effectively
tainted that VM for the rest of its lifetime. From the virt host
vendors' POV, any unexpected or problematic behaviour you get from
that VM thereafter will be outside scope of support. The onus would
be on the openstack sysadmin to demonstrate that the same problem
occurs without the use of live cloning.

Running a production cloud using a feature that your virt host
vendor considers unsupported would be somewhat reckless IMHO, unless
you think your sysadmins think they have the skills to solve all
possible problems in that area themselves, which is unlikely for most
cloud vendors.

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 :|

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] live-snapshot/cloning of virtual machines

2013-08-19 Thread Tim Smith 
On Sun, Aug 18, 2013 at 1:28 PM, Robert Collins
wrote:

> On 17 August 2013 07:01, Russell Bryant  wrote:
>
> >> Maybe we've grown up to the point where we have to be more careful and
> >> not introduce
> >> these kind of features and the maintenance cost of introducing
> >> experimental features is
> >> too great. If that is the community consensus, then I'm happy keep the
> >> live snapshot stuff
> >> in a branch on github for people to experiment with.
> >
> > My feeling after following this discussion is that it's probably best to
> > keep baking in another branch (github or whatever).  The biggest reason
> > is because of the last comment quoted from Daniel Berrange above.  I
> > feel that like that is a pretty big deal.
>
> So, reading between the lines here, I guess you're worried that we'd
> let code paths that violate what upstream will support leak into the
> main codepaths for libvirt - and thus we'd end up with a situation
> where we aren't supported by upstream for all regular operations.
>
> I agree that *that* is a big deal : is there something we could do to
> prevent that happening? E.g. annotating this whole thing as
> experimental/not upstream supported or something?
>

My understanding is that the live-snapshot extensions are to be disabled by
default (either on the driver side or the API side) and must be explicitly
enabled via a nova configuration change. Thus, it is not interferant with
mainline codepaths by default, and the user will not place themself into an
"unmaintainable" position unless they or their OpenStack distro provider
flips that particular switch.

That would seem to me a sufficiently high bar for preventing the user from
shooting themselves in the foot. As for any objections to the mere
_existence_ of the live-snapshot capability, I propose that the market
answer the question as to whether or not the feature has value.

Cheers,
Tim




> -Rob
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] live-snapshot/cloning of virtual machines

2013-08-18 Thread Robert Collins 
On 17 August 2013 07:01, Russell Bryant  wrote:

>> Maybe we've grown up to the point where we have to be more careful and
>> not introduce
>> these kind of features and the maintenance cost of introducing
>> experimental features is
>> too great. If that is the community consensus, then I'm happy keep the
>> live snapshot stuff
>> in a branch on github for people to experiment with.
>
> My feeling after following this discussion is that it's probably best to
> keep baking in another branch (github or whatever).  The biggest reason
> is because of the last comment quoted from Daniel Berrange above.  I
> feel that like that is a pretty big deal.

So, reading between the lines here, I guess you're worried that we'd
let code paths that violate what upstream will support leak into the
main codepaths for libvirt - and thus we'd end up with a situation
where we aren't supported by upstream for all regular operations.

I agree that *that* is a big deal : is there something we could do to
prevent that happening? E.g. annotating this whole thing as
experimental/not upstream supported or something?

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] live-snapshot/cloning of virtual machines

2013-08-16 Thread Russell Bryant 
On 08/16/2013 01:17 PM, Vishvananda Ishaya wrote:
> 
> 
> 
> On Fri, Aug 16, 2013 at 3:05 AM, Daniel P. Berrange  > wrote:

> I don't think it is a good idea to add a feature which is considered to
> be unsupportable by the developers of the virt platform.
> 
> 
> You make excellent points. I'm not totally convinced that this feature
> is the right
> long-term direction, but I still think it is interesting. To be fair,
> I'm not convinced that
> virtual machines as a whole are the right long-term direction. I'm still
> looking for a way
> for people experiment with this and see what use-cases that come out of it.
> 
> Over the past three years OpenStack has been a place where we can
> iterate quickly and
> try new things. Multihost nova-network was an experiment of mine that
> turned into the
> most common deployment strategy for a long time.
> 
> Maybe we've grown up to the point where we have to be more careful and
> not introduce
> these kind of features and the maintenance cost of introducing
> experimental features is
> too great. If that is the community consensus, then I'm happy keep the
> live snapshot stuff
> in a branch on github for people to experiment with.

My feeling after following this discussion is that it's probably best to
keep baking in another branch (github or whatever).  The biggest reason
is because of the last comment quoted from Daniel Berrange above.  I
feel that like that is a pretty big deal.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] live-snapshot/cloning of virtual machines

2013-08-16 Thread Andres Lagar-Cavilla 
> On Fri, Aug 16, 2013 at 11:05:19AM +0100, Daniel P. Berrange wrote:
>> On Wed, Aug 14, 2013 at 04:53:01PM -0700, Vishvananda Ishaya wrote:
>>> Hi Everyone,
>>> 
>>> I have been trying for some time to get the code for the live-snapshot 
>>> blueprint[1]
>>> in. Going through the review process for the rpc and interface code[2] was 
>>> easy. I
>>> suspect the api-extension code[3] will also be relatively trivial to get 
>>> in. The
>>> main concern is with the libvirt driver implementation[4]. I'd like to 
>>> discuss the
>>> concerns and see if we can make some progress.
>>> 
>>> Short Summary (tl;dr)
>>> =
>>> 
>>> I propose we merge live-cloning as an experimental feature for havanna and 
>>> have the
>>> api extension disabled by default.
>>> 
>>> Overview
>>> 
>>> 
>>> First of all, let me express the value of live snapshoting. The
>>> slowest part of the vm provisioning process is generally booting
>>> of the OS.
> 
> Like Dan I'm dubious about this whole plan.  But this ^^ statement in
> particular.  I would like to see hard data to back this up.

What we need to keep in mind is that "boot" is a small part of the picture, at 
least "boot" as commonly referred to in Linux.

Consider a web sphere-like Java bundle of code. These things take a while to 
load. JiT-ed methods provide a tremendous performance boost. Nevermind if the 
the server constructs secondary indices to perform fast lookups of data.

That is just Linux. Windows is well known for pounding storage fabrics with 
thousands of small reads during boot storms. Certainly a boot Windows sequence 
has baked in a lot of service startup sequences that prime a lot of memory 
content for performance objectives.

Boot here means "ready to rock-n-roll", not "Cirros is up."

We have live deployments that are based on bypassing the entire *application 
startup* sequence and have a server ready to provide high-performance responses 
to queries once spawned from a live saved image.


> 
> You should be able to boot an OS pretty quickly, and furthermore it's
> (a) much safer for all the reasons Dan outlines, and (b) improvements
> that you make to boot times help everyone.
> 
> [...]
>>> 2. Security Concerns
>>> 
>>> 
>>> There are a number of security issues with loading state from another vm. 
>>> Here is a
>>> short list of things that need to be done just to make a cloned vm usable:
>>> 
>>> a) mac address needs to be recreated
>>> b) entropy pool needs to be reset
>>> c) host name must be reset
>>> d) host keys bust be regenerated
>>> 
>>> There are others, and trying to clone a running application as well may 
>>> expose other
>>> sensitive data, especially if users are snaphsoting vms and making them 
>>> public.
> 
> Are we talking about cloning VMs that you already trust, or cloning
> random VMs and allowing random other users to use them?  These would
> lead to very different solutions.  In the first case, you only care
> about correctness, not security.  In the second case, you care about
> security as well as correctness.

Case number one.

The correctness issues are a hard problem, and a particularly hard one in 
Windows, but it is pragmatically solvable.

For a common scenario in Linux, renewing dhcp leases and leveling your entropy 
pool are what you need.

> 
> I highly doubt the second case is possible because scrubbing the disk
> is going to take far too long for any supposed time-saving to matter.

That would be very counter-productive, so yes, focusing on the first case.
> 
> As Dan says, even the first case is dubious because it won't be correct.
> 
>> The libguestfs project provide tools to perform offline cloning of
>> VM disk images.  Its virt-sysprep knows how to delete alot (but by
>> no means all possible) sensitive file data for common Linux &
>> Windows OS. It still has to be combined with use of the
>> virt-sparsify tool though, to ensure the deleted data is actually
>> purged from the VM disk image as well as the filesystem, by
>> releasing all unused VM disk sectors back to the host storage (and
>> not all storage supports that).
> 
> Links to the tools that Dan mentions:
> 
> http://libguestfs.org/virt-sysprep.1.html
> http://libguestfs.org/virt-sparsify.1.html

Virt-sparsify is not strictly relevant here. The disk side of live images is 
carried out with qcow2.

Virt-sysprep is great work and highly relevant.

But virt-sysprep allows us to see the argument in a different light. Have you 
noticed nova does not run virt-sysprep before booting an ephemeral instance 
from an image? (AFAIK, could be wrong, not even regenerating host ssh keys is 
part of the assured workflow). Furthermore, one can create arbitrary (cold, 
non-live) images at any time, from live instances

This isn't necessarily wrong. It underpins massive deployments, it 
pragmatically adds value. The fundamental semantics at play with live-instances 
are the same: know what you are doing, ephemeral instances,

Re: [openstack-dev] [nova] live-snapshot/cloning of virtual machines

2013-08-16 Thread Vishvananda Ishaya 
On Fri, Aug 16, 2013 at 3:05 AM, Daniel P. Berrange wrote:

> On Wed, Aug 14, 2013 at 04:53:01PM -0700, Vishvananda Ishaya wrote:
> > Hi Everyone,
> >
> > I have been trying for some time to get the code for the live-snapshot
> blueprint[1]
> > in. Going through the review process for the rpc and interface code[2]
> was easy. I
> > suspect the api-extension code[3] will also be relatively trivial to get
> in. The
> > main concern is with the libvirt driver implementation[4]. I'd like to
> discuss the
> > concerns and see if we can make some progress.
> >
> > Short Summary (tl;dr)
> > =
> >
> > I propose we merge live-cloning as an experimental feature for havanna
> and have the
> > api extension disabled by default.
> >
> > Overview
> > 
> >
> > First of all, let me express the value of live snapshoting. The slowest
> part of the
> > vm provisioning process is generally booting of the OS. The advantage of
> live-
> > snapshotting is that it allows the possibility of bringing up
> application servers
> > while skipping the overhead of vm (and application startup).
>
> For Linux at least I think bootup time is a problem that is being solved
> by the
> distros. It is possible to boot up many modern Linux distros in a couple
> of seconds
> even in physical hardware - VMs can be even faster since they don't have
> such stupid
> BIOS to worry about & have a restricted set of possible hardware. This is
> on a par
> with, or better than, the overheads imposed by Nova itself in the boot up
> process.
>
> Windows may be a different story, but I've not used it in years so don't
> know what
> its boot performance is like.
>
> > I recognize that this capability comes with some security concerns, so I
> don't expect
> > this feature to go in and be ready to for use in production right away.
> Similarly,
> > containers have a lot of the same benefit, but have had their own
> security issues
> > which are gradually being resolved. My hope is that getting this feature
> in would
> > allow people to start experimenting with live-booting so that we could
> uncover some
> > of these security issues.
> >
> > There are two specific concerns that have been raised regarding my
> patch. The first
> > concern is related to my use of libvirt. The second concern is related
> to the security
> > issues above. Let me address them separately.
> >
> > 1. Libvirt Issues
> > =
> >
> > The only feature I require from the hypervisor is to load
> memory/processor state for
> > a vm from a file. Qemu supports this directly. The only way that libvirt
> exposes this
> > functionality is via its restore command which is specifically for
> restoring the
> > previous state of an existing vm. "Cloning", or restoring the memory
> state of a
> > cloned vm is considered unsafe (which I will address in the second
> point, below).
> >
> > The result of the limited api is that I must include some hacks to make
> the restore
> > command actually allow me to restore the state of the new vm. I
> recognize that this
> > is using an undocumented libvirt api and isn't the ideal solution, but
> it seemed
> > "better" then avoiding libvirt and talking directly to qemu.
> >
> > This is obviously not ideal. It is my hope that this 0.1 version of the
> feature will
> > allow us to iteratively improve the live-snapshot/clone proccess and get
> the security
> > to a point where the libvirt maintainers would be willing to accept a
> patch to directly
> > expose an api to load memory from a file.
>
> To characterize this as a libvirt issue is somewhat misleading. The reason
> why libvirt
> does not explicitly allow this, is that from discussions with the upstream
> QEMU/KVM
> developers, the recommendation/advise that this is not a safe operation
> and should not
> be exposed to application developers.
>
> The expectation is that the functionality in QEMU is only targetted for
> taking point in
> time snapshots & allowing rollback of a VM to those snapshots, not
> creating clones of
> active VMs.
>

Thanks for the clarification here. I wasn't aware that this requirement
came from qemu
upstream.


>
> > 2. Security Concerns
> > 
> >
> > There are a number of security issues with loading state from another
> vm. Here is a
> > short list of things that need to be done just to make a cloned vm
> usable:
> >
> > a) mac address needs to be recreated
> > b) entropy pool needs to be reset
> > c) host name must be reset
> > d) host keys bust be regenerated
> >
> > There are others, and trying to clone a running application as well may
> expose other
> > sensitive data, especially if users are snaphsoting vms and making them
> public.
> >
> > The only issue that I address on the driver side is the mac addresses.
> This is the
> > minimum that needs to be done just to be able to access the vm over the
> network. This
> > is implemented by unplugging all network devices before the snapshot and
> plugging new
> > networ

Re: [openstack-dev] [nova] live-snapshot/cloning of virtual machines

2013-08-16 Thread Daniel P. Berrange 
On Wed, Aug 14, 2013 at 04:53:01PM -0700, Vishvananda Ishaya wrote:
> Hi Everyone,
> 
> I have been trying for some time to get the code for the live-snapshot 
> blueprint[1]
> in. Going through the review process for the rpc and interface code[2] was 
> easy. I
> suspect the api-extension code[3] will also be relatively trivial to get in. 
> The
> main concern is with the libvirt driver implementation[4]. I'd like to 
> discuss the
> concerns and see if we can make some progress.
> 
> Short Summary (tl;dr)
> =
> 
> I propose we merge live-cloning as an experimental feature for havanna and 
> have the
> api extension disabled by default.
> 
> Overview
> 
> 
> First of all, let me express the value of live snapshoting. The slowest part 
> of the
> vm provisioning process is generally booting of the OS. The advantage of live-
> snapshotting is that it allows the possibility of bringing up application 
> servers
> while skipping the overhead of vm (and application startup).

For Linux at least I think bootup time is a problem that is being solved by the
distros. It is possible to boot up many modern Linux distros in a couple of 
seconds
even in physical hardware - VMs can be even faster since they don't have such 
stupid
BIOS to worry about & have a restricted set of possible hardware. This is on a 
par
with, or better than, the overheads imposed by Nova itself in the boot up 
process.

Windows may be a different story, but I've not used it in years so don't know 
what
its boot performance is like.

> I recognize that this capability comes with some security concerns, so I 
> don't expect
> this feature to go in and be ready to for use in production right away. 
> Similarly,
> containers have a lot of the same benefit, but have had their own security 
> issues
> which are gradually being resolved. My hope is that getting this feature in 
> would
> allow people to start experimenting with live-booting so that we could 
> uncover some
> of these security issues.
> 
> There are two specific concerns that have been raised regarding my patch. The 
> first
> concern is related to my use of libvirt. The second concern is related to the 
> security
> issues above. Let me address them separately.
> 
> 1. Libvirt Issues
> =
> 
> The only feature I require from the hypervisor is to load memory/processor 
> state for
> a vm from a file. Qemu supports this directly. The only way that libvirt 
> exposes this
> functionality is via its restore command which is specifically for restoring 
> the
> previous state of an existing vm. "Cloning", or restoring the memory state of 
> a
> cloned vm is considered unsafe (which I will address in the second point, 
> below).
> 
> The result of the limited api is that I must include some hacks to make the 
> restore
> command actually allow me to restore the state of the new vm. I recognize 
> that this
> is using an undocumented libvirt api and isn't the ideal solution, but it 
> seemed
> "better" then avoiding libvirt and talking directly to qemu.
> 
> This is obviously not ideal. It is my hope that this 0.1 version of the 
> feature will
> allow us to iteratively improve the live-snapshot/clone proccess and get the 
> security
> to a point where the libvirt maintainers would be willing to accept a patch 
> to directly
> expose an api to load memory from a file.

To characterize this as a libvirt issue is somewhat misleading. The reason why 
libvirt
does not explicitly allow this, is that from discussions with the upstream 
QEMU/KVM
developers, the recommendation/advise that this is not a safe operation and 
should not
be exposed to application developers.

The expectation is that the functionality in QEMU is only targetted for taking 
point in
time snapshots & allowing rollback of a VM to those snapshots, not creating 
clones of
active VMs.

> 2. Security Concerns
> 
> 
> There are a number of security issues with loading state from another vm. 
> Here is a
> short list of things that need to be done just to make a cloned vm usable:
> 
> a) mac address needs to be recreated
> b) entropy pool needs to be reset
> c) host name must be reset
> d) host keys bust be regenerated
> 
> There are others, and trying to clone a running application as well may 
> expose other
> sensitive data, especially if users are snaphsoting vms and making them 
> public.
> 
> The only issue that I address on the driver side is the mac addresses. This 
> is the
> minimum that needs to be done just to be able to access the vm over the 
> network. This
> is implemented by unplugging all network devices before the snapshot and 
> plugging new
> network devices in on clone. This isn't the most friendly thing to guest 
> applications,
> but it seems like the safest option for the first version of this feature.

This is not really as safe as you portray. When restoring from the snapshot the 
VM
will initially be running with virtual NIC with a different