On Fri, Mar 2, 2018 at 9:00 AM, Mick <michaelkintz...@gmail.com> wrote:
> On Friday, 2 March 2018 11:34:09 GMT Peter Humphrey wrote:
>> On Friday, 2 March 2018 11:12:36 GMT Helmut Jarausch wrote:
>> > Hi,
>> > I'd like to install a second Gentoo system on a partition by running
>> > QEMU using that partition (directly) - this is to create and update a
>> > Gentoo
>> > system with different CFLAGS (for an older machine).
> The QEMU guest's complete filesystem is contained within a *virtual* disk
> image. As far as the host OS is concerned, the guest's disk with all
> partitions on it, is a file. You can store this image file wherever you want
> and map the QEMU on the host to launch it.
You can pass a block device directly to QEMU, and this is recommended
for performance reasons. I have a Windows 10 VM that was passed an
entire SSD; it runs fine, and you can take the disk and plug it into
other computers. Passing a partition is a little different, if you
wish to load it directly, you would need to chainload it with GRUB, as
the MBR/GPT information would be duplicated.
All OP needs to do is pass something like "-drive
file=/dev/block,if=virtio". There should be more options, such as AIO
implementation, but you likely won't need to mess with them.
>> > Having no experience in such setups my initial problem is how to
>> > install grub2 on that partition (only). I don't want to modify the MBR
>> > of the whole drive containing that partition.
> You do not install the guest's GRUB or any other boot loader on the host's
> partition. You install it within the virtual disk after you have launched the
> guest having attached a LiveCD to it, using QEMU.
If you pass a block device the MBR/GPT information will be stored
there. In the case of passing a partition, this means you can't boot
it "directly" because the BIOS/EFI firmware can't read it.
>> I do the same for my Atom machine by NFS-exporting its /usr/portage to a
>> chroot on my main machine. The question of booting doesn't arise; all that's
>> needed is a copy of /etc/portage* and the world file. If that sounds
>> interesting I can show you some more detail.
>> * Things like -march and --jobs differ to suit the host machine, but that's
>> about all.
> As noted above you'll need to set up CFLAGS in the guest's make.conf file to
> suit the *guest* platform and its CPU. Setting up "-march=native" won't work
QEMU should, by default, emulate the host processor exactly if your
machine has VT-x. The VM runs directly on the processor and all
instructions are available except the virtualization ones, but you can
enable nested VT-x or the AMD equivalent.