VirtIO on RHEL and Fedora -performance difference between

I was not intentionally pursuing this particular validation, but I discovered that the DiskI/O on RHEL 6.2 seems to be much faster than Fedora 16.

So - I am using the same exact laptop for both installations. I do format the volume between each base OS installation.
I am using a Lenovo T520 with a 750 Gig 7200 RPM drive (don't recall specifically which one).
I have been switching between using Fedora 16 and RHEL 6.2, both x86_64, as my base OS on my laptop. Each platform has some minor shortcomings and I happen to have some time at the moment to work through a few things.

When I installed Windows 7 Pro x64 using KVM on Fedora 16, I would be lucky to have iostat report much more than 15000 Blk_wrtn/s. I built the machine via the VMM using the VirtIO disk, NIC and Spice.
I am currently installing Windows 7 Pro using RHEL as base OS and I just happened to glance at my iostat output and it said around 115,000! Consistently reporting above 50,000. The total installation will take around 10 minutes, as opposed to around 40 with Fedora.

I look forward to discovering what * I * am doing wrong with Fedora to make it perform that way. The Windows 7 Guest VM seems notably "snappier", but time will tell regarding that.

So - why am I here...

Fedora 16 and VMware 8.0.2 - UGGGGG... is a good descriptor to start the discussion (pointing at VMware mostly). For some reason using Gnome Shell 3 and VMware, the Desktop Manager would basically lock up, or freeze. The mouse was still active, but... you couldn't click on anything, or type in that display. Good times. Using Compiz instead of Gnome Shell seems to mitigate this problem. However, before moving to Fedora, I was using my VMs quite often for random things, sometimes even to check man pages. However, now due to this particular issue I would only fire up the VM for very specific things, like Visio or Office.

So - why don't I just use RHEL and forget about the Fedora Problem? I have grown quite attached to my music collection (currently upwards of 12,000 tracks). Even if/when I get all the necessary packages installed for Rhythmbox, that app simply is not adequate for my needs. There does not appear to be a decent port of either Banshee or Amarok for RHEL either (rpmForge might have them, but I have decided to stick with EPEL and rpmFusion).

Plus - I am rather fond of Fedora 16 and Gnome Shell. It is quite strange to admit as I had a very tough time transitioning (perhaps I'm just getting old?).

But....I am an RHCE, on my path to more greatness, I should fully embrace my platform and make it work for me... and that now includes using KVM(QEMU) as my desktop virtualization platform.

PXE boot a LiveCD image

Summary: I have wanted to build a kickstart environment which hosted a "rescue CD" or LiveCD to allow you to boot over the network after you blew your stuff up and needed to repair a few things. Today I have worked through a method of doing so, with the help of the people who published a succinct script with the Red Hat Enterprise Virtualization Hypervisor. (the script will be at the bottom of this post - if I have somehow not followed the GPL, please let me know and I will correct whatever is necessary) NOTE/Warning: The boot will fail due the initrd being too large (645mb). I'm not sure how to proceed. This procedure worked for RHEVh, because it is quite a bit smaller. Hopefully I can report back with progress on this? :-$ Procedure: download your LiveCD image to /export/isos/RESCUE/Fedora-16-i686-Live-Desktop.iso # cd /var/tmp # vi livecd-iso-to-pxeboot (populate the file with the script shown below) # chmod 754 ./livecd-iso-to-pxeb...

"Error getting authority: Error initializing authority: Could not connect: No such file or directory (g-io-error-quark, 1)"

"Error getting authority: Error initializing authority: Could not connect: No such file or directory (g-io-error-quark, 1)" One issue that may cause this to arise is if you managed to break your /etc/fstab We had an engineer add a line with the intended options of "nfsvers=3" but instead added "-onfsvers=3" and it broke the system fairly catastrophically.

P2V using dd for KVM-QEMU guest

Preface: I have certainly not exhaustively tested this process. I had a specific need and found a specific solution that worked. Situation: I was issued a shiny new laptop running Red Hat Enterprise Linux 7 (with Corp VPN, certs, Authentication configuration, etc...) The image was great, but I needed more flexibility on my bare metal. So, my goal was to P2V the corporate image so I could just run it as a VM. * Remove corporate drive and install new SSD * install corp drive in external USB-3 case * Install RHEL 7 on new SSD * dd old drive to a disk-image file in a temp location which will be an image which is the same size as your actual drive (unless you have enough space in your destination to contain a temp and converted image) * convert the raw disk-image to a qcow file while pushing it to the final location - this step should reduce the disk size - however, I believe it will only reduce/collapse zero-byte blocks (not just free space - i.e. if you de...

Unix Revolution

Search This Blog