On 17/05/15 21:32, Steve Litt wrote:
> On Sat, 16 May 2015 17:12:04 +0800
> Brad Campbell <lists2009@???> wrote:
>
>> On 16/05/15 07:37, Steve Litt wrote:
>>
>>> When you accidentally bork a Qemu VM such that it won't boot to a
>>> virtual terminal, how do you bust back in. I doubt System Rescue CD
>>> would help, unless you can boot from the "cdrom" but somehow also
>>> access the existing "hard disk" borked VM image.
>>>
>>> So how do you bust back into a borked VM?
>>
>> With systemrescuecd.
>> qemu -hda my.img -cdrom /path/to/sysresccd.iso -boot d
>>
>> Easy peasy.
>>
>> Brad
>
> Thanks Brad,
>
> Your method both worked and was dead bang easy. Yesterday I performed
> this procedure about 10 times in 2 hours. Note that System Rescue CD
> requires -vga std in order to have anything resembling a decent image.
> And of course I used --enable-kvm so I wouldn't get gray hair waiting
> for it to boot.

While I'm here there is another qemu trick I find handy.
I have a requirement to run bespoke software that relies on various
versions of windows (specifically 2003 & 7) and I need a _fast_ machine
to run them. I procured a nice fast SSD and partitioned it up, and I
pass the *partitions* to qemu.. so

qemu -hda /dev/sdb1

This makes the guest think its running in a disk of $partition size.
This can then be partitioned in the guest. So a partition inside a
partition. I can access these from the host with kpartx, but it prevents
windows from seeing anything else on the machine (most of all the other
version of windows next door) but leaves me with the performance of a
raw partition and native IO.

I have loads of little qemu guest files with everything from dos through
to windows & macos. When I need to rescue anything I can just run up
that VM with the hard disk or partition passed through. I use
systemrescuecd a _lot_ though.

When testing new OS variants, I use a qcow2 guest file, and snapshot it
before making changes. That makes it super quick and easy to roll back.

Regards,
Brad