Re: [Qemu-devel] Guest kernel device compatability auto-detection
From a security perspective, this not a great idea. Security isolation in virtualization is gaining ground, so anything that breaches the hypervisor/guest vale is by your typical enterprise/company security team considered completely illegal, a number of firms I have talked with all are talking about how their respective security teams are raising all kinds of hell/red flags, demanding disablement of features that breach the vale. I would ask two things be done in the design if it goes forward, 1) have an explicit way to disable this feature, where the hypervisor cannot interact with the guest OS directly in any way if disablement is selected. 2) implement the feature as an agent in the guest OS where the hypervisor can only query the guest OS agent, using a standard TCP/IP methodology. Any under the hood, under the covers methodology, I can tell you for a fact, security teams will quash, or demand the feature is disabled. This goes for VM to VM communication as well that does not use a formal TCP/IP stack based method as well. Security teams want true OS isolation, point blank. Schorschi Decker VP; Sr. Consultant Engineer ECTO Emerging Technologies / Virtualization Platform Engineering Team Bank of America Office 213-345-4714 -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Richard W.M. Jones Sent: Thursday, 25 August, 2011 03:01 To: qemu-devel@nongnu.org Cc: Avi Kivity; kvm Subject: Re: [Qemu-devel] Guest kernel device compatability auto-detection On Thu, Aug 25, 2011 at 08:48:25AM +0100, Richard W.M. Jones wrote: On Thu, Aug 25, 2011 at 10:40:34AM +0300, Sasha Levin wrote: From what I gathered libguestfs only provides access to the guests' image. Correct. Which part is doing the IKCONFIG or System.map probing? Or is it done in a different way? You'll have to see what Matt's doing in the virt-v2v code for the details, but in general we have full access to: - grub.conf (to determine which kernel will boot) - the kernel image - the corresponding System.map and config - the modules directory - the Xorg config - boot.ini or BCD (to determine which NT kernel will boot) - the Windows Registry - the list of packages installed (to see if VMware-tools or some other guest agent is installed) So working out what drivers are available is just a tedious matter of iterating across each of these places in the filesystem. We had some interesting discussion on IRC about this. Detecting if a guest supports virtio is a tricky problem, and it goes beyond what the guest kernel can do. For Linux guests you also need to check what userspace can do. This means unpacking the initrd and checking for virtio drivers [in the general case this is intractable, but you can do it for specific distros]. You also need to check that udev has the correct rules and that LVM is configured to see VGs on /dev/vd* devices. Console and Xorg configuration may also need to be checked (for virtio-console and Cirrus/QXL support resp.) virt-v2v does quite a lot of work to *enable* virtio drivers including: - possibly installing a new kernel and updating grub - rebuilding the initrd to include virtio drivers - adjusting many different config files - removing other guest tools and Xen drivers - reconfiguring SELinux - adding viostor driver to Windows and adjusting the Windows Registry Critical Device Database Of course virt-v2v confines itself to specific known guests, and we test it like crazy. Here is the code: http://git.fedorahosted.org/git/?p=virt-v2v.git;a=blob;f=lib/Sys/VirtConvert/Converter/RedHat.pm;hb=HEAD http://git.fedorahosted.org/git/?p=virt-v2v.git;a=blob;f=lib/Sys/VirtConvert/Converter/Windows.pm;hb=HEAD Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any
Re: [Qemu-devel] [virt-tools-list] Virt Tools Survey: What to do about virt-clone
(a) Is cloning guests useful for you or not? Often or infrequently? Our end-users are quite virtualization aware, they have demanded that we support a number of features in our virtual infrastructure, this included. It will be used frequently and often, maybe 100s of times a day across our global infrastructure. (b) Do you currently use virt-clone to clone guests? Only in the lab, cloning or templating is a new initiative in our maturing design, so the timing of revamping this is perfect for our plans over the next few months. (c) Do you have a homebrew method to clone guests? What does it do? Yes, we often migrate and/or clone VMs in the lab between VMware and KVM and Hyper-V and back again. VMware and KVM is quite easy, given the flexibility of common shared storage support and VM disks in RAW format adaptable to VMware and KVM. Hyper-V has its own challenges given its limitations by design. For VMware to KVM and back, we have a few bash scripts that we use. Migrations are straight-forward, since no personality customization is needed, but true clones, which we use for SPECVirt analysis for example, we have to remove/reapply personality. This is not trivial, since we have a lot of applications in our base image that are infrastructure aware, and require reconfiguration, or re-initialization, beyond the typical sysprep or OS level changes. Windows is especially painful on this point. Our personality management scripting is in a constant state of change because we are routinely updating our core images. (d) Do you use another tool to clone guests? (And how is it?) We have used platespin off and on, and of course use various tools and methods core to WAIK tool set for Windows. But custom scripting is the significant 800 pound gorilla in the room on this point. A specific in VM agent or service that would explicitly support re-personalization regardless of OS or application level would be of great benefit, since meta-data or a back-end database could drive the re-personalization, provided a more stateless model. Especially for Windows this might be an idea worth consideration. BladeLogic, Ops-ware, Altaris, etc. all use some form of this idea, but they are also focused on provisioning in general so the meta-data driven re-personalization gets lost in the overall product. (e) When you clone a guest, do you sysprep it or would you like to? (Using the term sysprep generically here, I mean any sort of reinitialization for Linux or Windows guests). Sysprep is fine as a place to start, but even when Microsoft wrote sysprep, it was an idea that was ignored for a long time, and it was never focused on, the world has since gone forward, so sysprep is at best, only a starting point for what is needed to abstract personality. A better solution would be that we image/clone the personality specific deltas and archive them to a library, rather than complete clones that have personality logic staged for implementation on first boot. (f) How do you feel about a multi-step process? virt-clone - virt-sysprep - virt-resize (for example) As long as any GUI and CLI (as well as API) are consistent in feature set and flow, multi-step is fine. We need to be able to completely automate the process, since we would drive it from a self-serve web portal concept. (g) Have you had other problems with cloning guests? Nothing beyond what was outlined above. Abstracting of personality at OS and application level is key for us. (h) What have I missed out in this analysis? What other features have you missed in virt-clone? No specifically to virt-clone but in general, abstracting the common code, to common library or binary, so that virt-manager, virsh, etc. all reference the same design, feature, and executables, is the strategic direction that should be followed. The idea that different code is trying to implement same concepts in different tools makes no long term strategic sense for the KVM platform in general. Schorschi Decker VP; Sr. Consultant Engineer ETD Emerging Technologies / Virtualization Platform Engineering Team Bank of America -Original Message- From: virt-tools-list-boun...@redhat.com [mailto:virt-tools-list-boun...@redhat.com] On Behalf Of Richard W.M. Jones Sent: Tuesday, 10 May, 2011 04:57 To: virt-tools-l...@redhat.com; Cole Robinson Cc: v...@lists.fedoraproject.org; qemu-devel@nongnu.org Subject: [virt-tools-list] Virt Tools Survey: What to do about virt-clone I've volunteered for the task of fixing virt-clone[0]. There are a number of bugs which need to be addressed. Unfortunately the current virt-clone is broken-by-design since it cannot make changes inside the guest. [0] http://linux.die.net/man/1/virt-clone The bugs boil down to what Microsoft calls sysprepping the clone, which is to say, removing its existing identity, hostname, ssh host keys, persistent network rules, host SID and workgroup name (for Windows). It's helpful for Linux guests to remove some of
Re: [Qemu-devel] [virt-tools-list] Virt Tools Survey: What to do about virt-clone
Given a couple of questions I have gotten in response to my survey responses... let me clarify, although I imply we do a significant volume of V2V, which we do as well, the responses below are targeted and applicable to cloning. Especially the need to re-personalize clones beyond the OS scope to the application scope when and where possible. We maintain the original VMs in the original environment, often running clones in parallel on different environments, so cloning is done, both within the same hypervisor scope and across different hypervisor environments. Our work with SPECVirt is one concrete example where we use cloning routinely, to build multiple tiers or tiles. Our focus thus far has been in the lab/test/development space, but our client base is pushing for same flexibility in QA/production environments, so the need for better/mature tools and methods in the KVM space, including cloning, is key to our future goals. Schorschi Decker VP; Sr. Consultant Engineer ETD Emerging Technologies / Virtualization Platform Engineering Team Bank of America -Original Message- From: Decker, Schorschi Sent: Tuesday, 10 May, 2011 07:01 To: virt-tools-l...@redhat.com; Cole Robinson Cc: v...@lists.fedoraproject.org; qemu-devel@nongnu.org Subject: RE: [virt-tools-list] Virt Tools Survey: What to do about virt-clone (a) Is cloning guests useful for you or not? Often or infrequently? Our end-users are quite virtualization aware, they have demanded that we support a number of features in our virtual infrastructure, this included. It will be used frequently and often, maybe 100s of times a day across our global infrastructure. (b) Do you currently use virt-clone to clone guests? Only in the lab, cloning or templating is a new initiative in our maturing design, so the timing of revamping this is perfect for our plans over the next few months. (c) Do you have a homebrew method to clone guests? What does it do? Yes, we often migrate and/or clone VMs in the lab between VMware and KVM and Hyper-V and back again. VMware and KVM is quite easy, given the flexibility of common shared storage support and VM disks in RAW format adaptable to VMware and KVM. Hyper-V has its own challenges given its limitations by design. For VMware to KVM and back, we have a few bash scripts that we use. Migrations are straight-forward, since no personality customization is needed, but true clones, which we use for SPECVirt analysis for example, we have to remove/reapply personality. This is not trivial, since we have a lot of applications in our base image that are infrastructure aware, and require reconfiguration, or re-initialization, beyond the typical sysprep or OS level changes. Windows is especially painful on this point. Our personality management scripting is in a constant state of change because we are routinely updating our core images. (d) Do you use another tool to clone guests? (And how is it?) We have used platespin off and on, and of course use various tools and methods core to WAIK tool set for Windows. But custom scripting is the significant 800 pound gorilla in the room on this point. A specific in VM agent or service that would explicitly support re-personalization regardless of OS or application level would be of great benefit, since meta-data or a back-end database could drive the re-personalization, provided a more stateless model. Especially for Windows this might be an idea worth consideration. BladeLogic, Ops-ware, Altaris, etc. all use some form of this idea, but they are also focused on provisioning in general so the meta-data driven re-personalization gets lost in the overall product. (e) When you clone a guest, do you sysprep it or would you like to? (Using the term sysprep generically here, I mean any sort of reinitialization for Linux or Windows guests). Sysprep is fine as a place to start, but even when Microsoft wrote sysprep, it was an idea that was ignored for a long time, and it was never focused on, the world has since gone forward, so sysprep is at best, only a starting point for what is needed to abstract personality. A better solution would be that we image/clone the personality specific deltas and archive them to a library, rather than complete clones that have personality logic staged for implementation on first boot. (f) How do you feel about a multi-step process? virt-clone - virt-sysprep - virt-resize (for example) As long as any GUI and CLI (as well as API) are consistent in feature set and flow, multi-step is fine. We need to be able to completely automate the process, since we would drive it from a self-serve web portal concept. (g) Have you had other problems with cloning guests? Nothing beyond what was outlined above. Abstracting of personality at OS and application level is key for us. (h) What have I missed out in this analysis? What other features have you missed in virt-clone? No specifically to virt-clone but in general, abstracting
