Forgot your password?
typodupeerror
Red Hat Software Businesses Operating Systems Software Windows Linux

Red Hat Releases Windows Virtualization Code 183

Posted by samzenpus
from the show-me-yours-and-I'll-show-you-mine dept.
dan_johns writes "Only one month after Microsoft released Linux code to improve the performance of Linux guests on Windows, Red Hat has done the reverse. Red Hat has quietly released a set of drivers to improve the performance of Windows guests hosted on Linux's Kernel-based Virtual Machine (KVM) hypervisor. The netkvm driver is a network driver and viostor is a Storport driver to improve the performance of high-end storage. This release includes paravirtual block drivers for Windows. Linux and Windows — virtually coming together at last."
This discussion has been archived. No new comments can be posted.

Red Hat Releases Windows Virtualization Code

Comments Filter:
  • Re:A good thing. (Score:3, Informative)

    by shentino (1139071) on Wednesday August 26, 2009 @06:41PM (#29210245)

    MS only released it because they got caught violating the GPL.

  • Re:Lack of Caring (Score:3, Informative)

    by Anonymous Coward on Wednesday August 26, 2009 @06:58PM (#29210407)

    Way to display your ignorance! We're talking about paravirtualization, not the crappy performance you'll get from workstation or virtualbox. This is on par with esx, hyperv and xen. So, having better paravirtualization support for windows on kvm really leaves virtualbox completely in the dust. And I'm sure this is all done by ms and rh with a view to the server, not the guy who wants to virtualize xp to run cstrike.

  • by TheRaven64 (641858) on Wednesday August 26, 2009 @07:02PM (#29210443) Journal
    Paravirtualisation just means that you're using a set of simple interfaces to communicate with the hypervisor driver, rather than an emulated physical device. You're still sending commands from the guest to the hypervisor (or, in the case of Xen, to a privileged guest), and it is still completing them on your behalf by talking to the hardware. If anything, PV is more secure, because the code running outside the guest is much simpler than a full emulated device. If there's a bug in the host PV drivers that permits arbitrary code execution then it's possible to escape from the VM. If there's a bug in the host's device emulator, then it's possible to escape from the VM. The second is more likely, because the code is much more complicated. A Xen PV block device interface, for example, is about 200 lines of code.
  • by nxtw (866177) on Wednesday August 26, 2009 @07:26PM (#29210643)

    Yes, they expected it just like they expected people to extend Kerebos Authentication and XML filetypes right back at them. Microsoft embraces and extends OTHERS, they don't GET embraced and extended.

    No; Microsoft and Red Hat joined each others' virtualization validation programs. As a result, Red Hat will support Windows server operating systems on Red Hat's virtualization software. This support is a direct result of Red Hat participating in Microsoft's validation program [windowsservercatalog.com].

    The list of vendors participating in Microsoft's program includes other companies, such as VMware, Citrix, Cisco, Oracle, and Sun.

  • by Anthony Liguori (820979) on Wednesday August 26, 2009 @07:29PM (#29210665) Homepage

    I've always wondered how paravirtualizing some functions such as I/O or networking affects security.

    Say a VM gets compromised, and is able to do what it wants with the block devices, how tough would it be to get out of the VM? If malicious code is able to access the host's block device that runs in kernel mode and start running code directly on the host's OS, game over.

    Unlike Hyper-V and Xen, in KVM a paravirtual device looks an awful lot like an emulated device. For instance, virtio-net appears to the guest as a normal PCI device. It's quite conceivable that a hardware vendor could implement a physical virtio-net card if they were so inclined. In our backend, we implement virtio-net like any other emulated device.

    This means from a security perspective, it's just as secure as an emulated driver. It's implemented in userspace and can be sandboxed as an unprivileged user or through SELinux.

    VMware uses a similar model. Hyper-V and Xen prefer to not model hardware at all and use special hypervisor-specific paths. From a security perspective, the fact that these devices are on a different code path means that they have different security characteristics than emulated devices. For instance, in Xen, a paravirtual network device is backed directly in the domain-0 kernel so an exploit in the xenpv network device is much more severe than an exploit in a Xen emulated network device (since the device emulation happens in an unprivileged stub domain).

  • Re:Gentoo?? (Score:4, Informative)

    by Hurricane78 (562437) <deleted@slashd o t .org> on Wednesday August 26, 2009 @08:11PM (#29211029)

    Protip:

    PORTAGE_NICENESS="19"
    PORTAGE_IONICE_COMMAND="ionice -c 3 -p \${PID}
    FEATURES="${FEATURES} parallel-fetch cchache"
    CCACHE_DIR="/var/tmp/ccache"
    CCACHE_SIZE="1G"

  • Re:Gentoo?? (Score:3, Informative)

    by HeronBlademaster (1079477) <heron@xnapid.com> on Wednesday August 26, 2009 @08:48PM (#29211327) Homepage

    I like my protip better: Mount /usr/portage/var (or whatever portage's working directory is) on a 9GB ramdisk, and set MAKEOPTS to -j9.

  • Re:See! (Score:5, Informative)

    by Korin43 (881732) on Wednesday August 26, 2009 @09:02PM (#29211401) Homepage
    The NTFS drivers for Linux work pretty well.. And ext2 IFS [fs-driver.org] works except for:

    * Inodes that are larger than 128 bytes are not supported.
    * Access rights are not maintained. All users can access all the directories and files of an Ext2 volume. If a new file or directory is created, it inherits all the permissions, the GID and the UID from the directory where it has been created. There is one exception to this rule: a file (but not a directory) the driver has created always has cleared "x" permissions, it inherits the "r" and the "w" permissions only. See also section "What limitations arise from not maintaining access rights?".
    * The driver does not allow accessing special files at Ext2 volumes, the access will be always denied. (Special files are sockets, soft links, block devices, character devices and pipes.)
    * Alternate 8.3-DOS names are not supported (just because there is no place to store them in an Ext2 file system). This can prevent legacy DOS applications, executed by the NTVDM of Windows, from accessing some files or directories.
    * Currently the driver does not implement defragging support. So defragmentation applications will neither show fragmentation information nor defragment any Ext2 volume.
    * This software does not achieve booting a Windows operating system from an Ext2 volume.
    * LVM volumes are not supported, so it is not possible to access them.

  • by jamesh (87723) on Wednesday August 26, 2009 @09:46PM (#29211657)

    Fortunately a brave soul in the community stepped up and wrote a set of GPL drivers

    Yes. Me. :)

  • Re:Gentoo?? (Score:1, Informative)

    by aesiamun (862627) on Wednesday August 26, 2009 @11:00PM (#29212175) Homepage Journal

    You haven't run windows in a while, have you...at least nothing newer than WinME....

  • Re:See! (Score:3, Informative)

    by David Gerard (12369) <{ku.oc.draregdivad} {ta} {todhsals}> on Thursday August 27, 2009 @07:03AM (#29214815) Homepage

    This is actually entirely false for servers - server vendors make damn sure Linux works out the box. Dell, Sun or HP would never release an x86 server these days that doesn't run Linux perfectly. All of them will deal with Red Hat in paid support and (in my experience) happily treat CentOS as Red Hat for problem solving purposes.

    Random desktop crapware, yeah. But this virtualisation exercise is for the benefit of servers, after all.

That does not compute.

Working...