Hi, We are trying to clone VMs as follows: (VM1 is a virtual machine, with ip addr 10.10.10.1 <http://10.10.10.1/>, and we want to clone it as VM2, with ip addr 10.10.10.2 <http://10.10.10.2/>) both running on the same physical machine. 1) Save VM1 as VM1_save (using xm save) 2) copy VM1_save to VM2_save 3) Change the vmid and the IP address info in the saved file to that of VM2 (Any other information to be changed ?) 4) Restore VM1_save and VM2_save (using xm restore) This whole approach may be totally wrong. Would appreciate if you could tell me if we can do cloning with this approach of saving and restoring files. We do realise that such an approach will involve a lot of overhead with respect to time but currently we just want an easy way to clone VMs without playing around the kernel code. Thanks, Sowmya. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 11/8/05, sowmya dayanand <sowmyad@gmail.com> wrote:> (VM1 is a virtual machine, with ip addr 10.10.10.1, and we want to clone it > as VM2, with ip addr 10.10.10.2) both running on the same physical machine. > > 1) Save VM1 as VM1_save (using xm save) > 2) copy VM1_save to VM2_save > 3) Change the vmid and the IP address info in the saved file to that of VM2 > (Any other information to be changed ?) > 4) Restore VM1_save and VM2_save (using xm restore)The problem is that while you are probably sucessful in telling the host environment (xen + linux in domain0) that your cloned VM has IP 10.10.10.2, the Linux inside VM2 does not know that it is supposed to answer the new IP rather than 10.10.10.1, and will just silently drop all traffic on 10.10.10.2. It would probably be quite simple (and useful, see the Potemkin paper for instance) to have your domain answer any incoming IP, or to rewrite all ingoing and outgoing packets with a generic address, but you will need to hack either your guest Linux or the networking scripts in dom0 to make that happen. Best, Jacob _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
A very interesting test for save/restore. :-) As I tested in 7695 without modifying IP address for VM2, I found that VM1 and VM2 could be sucessfully restored, and each owns a different MAC address, though IP address is the same. In that way, maybe we can run "service network restart" to enable network.>-----Original Message----- >From: xen-devel-bounces@lists.xensource.com >[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of >Jacob Gorm Hansen >Sent: Tuesday, November 08, 2005 3:34 PM >To: sowmya dayanand >Cc: xen-devel@lists.xensource.com >Subject: Re: [Xen-devel] Cloning(making copies) of VMs > >On 11/8/05, sowmya dayanand <sowmyad@gmail.com> wrote: > >> (VM1 is a virtual machine, with ip addr 10.10.10.1, and we >want to clone it >> as VM2, with ip addr 10.10.10.2) both running on the same >physical machine. >> >> 1) Save VM1 as VM1_save (using xm save) >> 2) copy VM1_save to VM2_save >> 3) Change the vmid and the IP address info in the saved file >to that of VM2 >> (Any other information to be changed ?) >> 4) Restore VM1_save and VM2_save (using xm restore) > >The problem is that while you are probably sucessful in telling the >host environment (xen + linux in domain0) that your cloned VM has IP >10.10.10.2, the Linux inside VM2 does not know that it is supposed to >answer the new IP rather than 10.10.10.1, and will just silently drop >all traffic on 10.10.10.2. It would probably be quite simple (and >useful, see the Potemkin paper for instance) to have your domain >answer any incoming IP, or to rewrite all ingoing and outgoing packets >with a generic address, but you will need to hack either your guest >Linux or the networking scripts in dom0 to make that happen. > >Best, >Jacob > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> The problem is that while you are probably sucessful in telling the > host environment (xen + linux in domain0) that your cloned VM has IP > 10.10.10.2, the Linux inside VM2 does not know that it is supposed to > answer the new IP rather than 10.10.10.1, and will just silently drop > all traffic on 10.10.10.2. It would probably be quite simple (and > useful, see the Potemkin paper for instance) to have your domain > answer any incoming IP, or to rewrite all ingoing and outgoing packets > with a generic address, but you will need to hack either your guest > Linux or the networking scripts in dom0 to make that happen.I guess it might be nice (eventually) to have a set of "Xen guest tools", including a hotplug script that gets run on restore, enabling this sort of thing to be configured. The domain would be told about the new IP using xenstore. Of course, this doesn''t solve the immediate problem of making it work without hacking the code ;-) Cheers, Mark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
A more generic approach would probably question if one should save the IP address and such information when saving a VM. This is because information such as IP addresses are "perishable" ie they may not be valid when restoring the VM. Probably one should identify such information and selectively save such information?? -- thinking out aloud. DM On 11/9/05, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:> > The problem is that while you are probably sucessful in telling the > > host environment (xen + linux in domain0) that your cloned VM has IP > > 10.10.10.2, the Linux inside VM2 does not know that it is supposed to > > answer the new IP rather than 10.10.10.1, and will just silently drop > > all traffic on 10.10.10.2. It would probably be quite simple (and > > useful, see the Potemkin paper for instance) to have your domain > > answer any incoming IP, or to rewrite all ingoing and outgoing packets > > with a generic address, but you will need to hack either your guest > > Linux or the networking scripts in dom0 to make that happen. > > I guess it might be nice (eventually) to have a set of "Xen guest tools", > including a hotplug script that gets run on restore, enabling this sort of > thing to be configured. The domain would be told about the new IP using > xenstore. > > Of course, this doesn''t solve the immediate problem of making it work without > hacking the code ;-) > > Cheers, > Mark > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>A more generic approach would probably question if one should save the >IP address and such information when saving a VM. This is because >information such as IP addresses are "perishable" ie they may not be >valid when restoring the VM. > > Probably one should identify such information and selectively save >such information?? -- thinking out aloud.Yes... But you still need the guest''s help here - if its IP address changes, something needs to run ifconfig (or similar) else it''ll be restored and ignored messages to its new IP address. The current IP address setting in the config file relies on being able to set the IP on the kernel command line. The command line is only read at boot time, so when we restore we don''t get to change it. We really need some sort of daemon / hotplug script in the guest to react to this sort of thing. Cheers, Mark> >DM > >On 11/9/05, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote: >> > The problem is that while you are probably sucessful in telling the >> > host environment (xen + linux in domain0) that your cloned VM has IP >> > 10.10.10.2, the Linux inside VM2 does not know that it is supposed to >> > answer the new IP rather than 10.10.10.1, and will just silently drop >> > all traffic on 10.10.10.2. It would probably be quite simple (and >> > useful, see the Potemkin paper for instance) to have your domain >> > answer any incoming IP, or to rewrite all ingoing and outgoing packets >> > with a generic address, but you will need to hack either your guest >> > Linux or the networking scripts in dom0 to make that happen. >> >> I guess it might be nice (eventually) to have a set of "Xen guest >> tools", including a hotplug script that gets run on restore, enabling >> this sort of thing to be configured. The domain would be told about the >> new IP using xenstore. >> >> Of course, this doesn''t solve the immediate problem of making it work >> without hacking the code ;-) >> >> Cheers, >> Mark >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 15 Nov 2005 15:35:37 +0000, M.A. Williamson <maw48@cam.ac.uk> wrote:> We really need some sort of daemon / hotplug script in the guest to react > to this sort of thing.Only problem is if the hotplug script or daemon resides on an NFS-root then. In any case calling on domU userspace to do this will be error-prone and slow :-( I think the best thing would be a domU kernel module or similar that can obtain the new IP address from xenstore and do the ifconfig inside the domU kernel. Alternatively the guest could always have the same IP (say 10.0.0.1) and then in- and outgoing packets could be rewritten to the real IP on the fly, either by the domU or by some iptables magic in dom0. Jacob _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel