I believe you're thinking of VMotion, which is available for their ESX product. It allows you to move a guest from one ESX server to another on-the-fly. It doesn't require the guest to be shut down or quiesced in any way, just that the source and destination ESX servers have shared DASD and are linked via Gigabit ethernet. It's pretty slick.
-----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Dave Jones Sent: Wednesday, April 05, 2006 4:15 PM To: [email protected] Subject: Re: Freeze Linux Guests momentarily VM Ware offers a similar facility, called "virtual migration", I think. You can quiesce a guest, move it to a different PC (but one that is still attached to the original disks) and restart it. They market it as part of the high availability solution. Of course, doing such an operation on Intel architecture systems is much easier, imho, that trying to do it on S/390......for one thing, Intel does not farm out the i/o processing to the degree S/390 does to separate subsystems. But I do think that having such a capability would be useful in high availability, DR and backup situations. DJ Daniel P. Martin wrote: > "Back in the day..." meaning along about VM/HPO 4.2-ish, I had a local > mod that allowed me to temporarily freeze a virtual machine in place > by marking it as non-dispatchable. Once it dropped from queue, it > would just sit there until it was un-frozen and allowed to resume > work. At that same point in time, VMSAVE would sort of do the same > thing as hibernate - except it was prone to weirdness from things like > having pending hardware interrupts cleared when you resumed a virtual > machine. > > I don't hack CP so much these days, so I'm not sure what would be > required - or if current architecture would even allow - similar > chicanery these days. But *cough*Endicott*cough* it sure would be a > handy feature to have as part of the OS... > > -dan. > > Marcy Cortes wrote: > >> Some sort of suspend would be cool - imagine hibernating all your >> guests, doing your VM and/or HW maintenance, and having them just pop >> back up! Kind of like hibernate on the PC! >> >> But, it doesn't really exist. You'll either have to look at some >> backup from inside of the guest or if you really need to be 24/7, >> then you have to have redundancy in virtual servers - preferably not >> on the same HW and perhaps even not in the same data center location. >> >> >> Marcy Cortes >> >> "This message may contain confidential and/or privileged information. >> If you are not the addressee or authorized to receive this for the >> addressee, you must not use, copy, disclose, or take any action based >> on this message or any information herein. If you have received this >> message in error, please advise the sender immediately by reply >> e-mail and delete this message. Thank you for your cooperation." >> >> >> -----Original Message----- >> From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of >> Tyler Koyl >> Sent: Wednesday, April 05, 2006 10:42 AM >> To: [email protected] >> Subject: [LINUX-390] Freeze Linux Guests momentarily >> >> I am quite sure this exists but I need a little help. >> >> I was wondering if there is a way to place a z/VM 5.1 linux guest >> into a froozen state? My thinking is just place the guest into a CP >> Read State. Can't seem to find the command to send a guest a request >> to enter CP READ. >> >> I am writing a REXX exec to handle the snapping. The logic I am >> looking for is >> this: >> >> /* >> Backup guest x >> - Place a guest is CP READ state (Or something similar) >> - Snap Guest related DASD (SVAA Snapshot) >> - Release Guest >> >> Repeat for each guest to be snapped. >> */ >> >> It has been mandated that the guests will be 24/7 so they cannot be >> logged off to do the backup, nor can the portal services etc be >> turned off. I am worried about sequential snapping DASD that belong >> to an LVM group so this is why I am looking for a work around. >> >> Any help is appreciated. >> >> Tyler Koyl >> Saskatchewan Wheat Pool >> Regina, Saskatchewan, Canada >> >> >> >> This e-mail and any attachment(s) are confidential and may be >> privileged. If you are not the intended recipient please notify me >> immediately by return e-mail, delete this e-mail and do not copy, use >> or disclose it. >> >> --------------------------------------------------------------------- >> - >> For LINUX-390 subscribe / signoff / archive access instructions, send >> email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or >> visit http://www.marist.edu/htbin/wlvindex?LINUX-390 >> >> --------------------------------------------------------------------- >> - >> For LINUX-390 subscribe / signoff / archive access instructions, >> send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 >> or visit >> http://www.marist.edu/htbin/wlvindex?LINUX-390 >> > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, send > email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or > visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
