[ovirt-users] Help with a vdsm hook script script?
I have not coded much python, but I'm having a go at trying to get a vdsm hook
script working.
What it is supposed to do is look for a controller of model 'virtio-scsi' in
the domxml and change the model to 'ich9-ahci'.I've named the script
'50_change_scsi_controller' and have placed it in
'/usr/libexec/vdsm/hooks/before_vm_start' on the one (and only) host in the
cluster where I'm doing this testing. I've set the perms to 755.I've also
added the custom property to my engine like so: engine-config -s
UserDefinedVMProperties='change_scsi_controller=.*' --cver=3.5I've restarted
the ovirt-engine like so 'service ovirt-engine restart' , and can now see the
custom property in the GUI config for a powered off VM that is set to boot up
into my cluster. I've put a string into the 'change_scsi_controller' property
and booted up the VM.The scsi controller model is not changed from
'virtio-scsi' to 'ich9-ahci'
On the host when I look at '/var/log/vdsm/vdsm.log' I can see tha tthe hook is
getting called, but I'm not sure what I need to look at here specifically? Can
anyone assist and possibly tell me what is wrong here? Is it an issue with my
python hook script?
I'm wanting to test an EL5 based install with a scsi disk, and EL5 does not
support virtio-scsi.
I should also mention that I know there are issues with migrating VMs that use
the ich9-ahci sata controller and I don't plan to use this long term. If I do
need this functionality I'll likely set up some Fedora hosts in another cluster
and use one of the other scsi controller types instead - ie: 'lsi53c810',
'lsi53c895a', 'megasas', 'pvscsi'.
Here's the hook script code:
#!/usr/bin/python
import os
import hooking
def main():
if hooking.tobool(os.environ.get('change_scsi_controller')):
newscsiadapter = hooking.read_json()
domxml = hooking.read_domxml()
for controller in domxml.getElementsByTagName('controller'):
filterValue = controller.getAttribute('model')
if filterValue == 'virtio-scsi':
filterValue.setAttribute('model','ich9-ahci')
hooking.write_domxml(domxml)
if __name__ == '__main__':
main()
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] updated qemu-kvm for EL7
Hello.I'm just following up on an mailing list exchange from earlier in the month that was asking about the possibility of an updated libvirt for EL7.Sandro mentioned that this was being talked about but that the vdsm team had worked around the issue and could do what they needed with the existing supplied libvirt on EL7.I've used a different subject this time to keep the topic more obvious to where the discussion has evolved to. Sandro mentioned that the qemu-kvm-ev that is being built - and available on the cbs.centos.org - would be used in master and also 3.5.x to fix a bug present in the currently used qemu-kvm under certain circumstances. A question was asked about live-merge functionality on EL7, and apparently this was being investigated.My initial thought is that if we are already going to a newer version of qemu-kvm than the distro supplied version, then why wouldn't ovirt want to try and be fairly current with the version they use/consume? Why not provide live snapshot merging on this platform? Why push users over to Fedora? Many potential users won't want to use Fedora on their hosts for a number of reasons.We currently provide qemu-kvm-ev-2.1.2-23.el7.1 on cbs.centos.org. Qemu 2.3 was released earlier this month. Are there any plans to bump the qemu-kvm version we currently consume? It would be interesting to hear the rationale around what version we use/should be using. Thanks,Paul ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] updated libvirt for EL7?
Hello.I came across a message posting from Sandro from a couple of weeks back that was about providing a libvirt 1.2.9 for some upstream VDSM testing.I would actually be interested in a newer libvirt to take advantage of some of the newer capabilities there. For now I've found this repo - https://repos.fedorapeople.org/repos/openstack/.virt-upstream-el7/ - which has libvirt 1.2.11 packages, built as or later December 2014. Are we likely to see a newer libvirt appear for EL7 somewhere on cbs.centos.org at some stage in the near future? I'd also be interested in newer qemu-kvm-ev packages if these will be built. I'm currently using the qemu-kvm-ev packages from here - http://cbs.centos.org/repos/virt7-testing/x86_64/os/Packages/ Alternatively, is there some other repository that I can look to for these?To preempt the question - I don't want to use Fedora for this and am instead hoping to find EL7 packages as EL7 is currently standard in my lab. Thanks in advance. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] making use of an existing NFS exported iso repository
Hello.I've done some searching through the mail archives on this and haven't come up with a suitable answer as of yet.I have a 3.5 cluster with currently no iso domain attached.I am unable to add an iso domain of type 'ISO / Local on host' as the 'host' drop down box is empty. I thought about exporting an iso directory on the engine machine via NFS and then symlinking into it a mount to the actual iso store, but the 're-exporting an NFS mounted filesystem' issue bit me there. When I looked inside the directory it was empty on hosts that had mounted the new iso share. Is there a solution to this problem at the moment? I don't want to have to copy iso files somewhere else on the network. I notice there have been quite a few requests over the years for being able to use an existing iso repository. Thanks. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] disk ordering
Hello Vered.This is when doing an EL6 install. Disk 1 - which also has the bootable flag turned on in ovirt - sometime does not show up as SDA inside the OS. The secondary disk shows as SDA and the first disk shows as SDB. This is with both disks as virtio -scsi disks.Unfortunately this behaviour is not consistent, it does happen every now and then though.. A colleague hit this issue again last night. From: Vered Volansky ve...@redhat.com To: Paul Jansen vla...@yahoo.com.au Cc: users users@ovirt.org Sent: Wednesday, 17 December 2014, 22:10 Subject: Re: [ovirt-users] disk ordering Hi Paul, Please explain what disk ordering you are referring to. Disk ordering displayed when and where exactly? Thanks, Vered - Original Message - From: Paul Jansen vla...@yahoo.com.au To: users users@ovirt.org Sent: Wednesday, December 17, 2014 3:12:50 AM Subject: [ovirt-users] disk ordering Hello. I've noticed issues with inconsistent disk ordering when doing installs from time to time (on VMs with two disks). I came across this post from Itamar from October 2013 where 'disk ordering' is mentioned as a roadmap item: [Users] oVirt Roadmap feature requests - Summary I haven't found anything more when doing searches. Has any work been done on this, or is there a workaround? This is a little annoying. I never run into this issue under Vmware's ESXi. [Users] oVirt Roadmap feature requests - Summary [Users] oVirt Roadmap feature requests - Summary Itamar Heim iheim at redhat.com Sun Oct 6 15:55:33 EDT 2013 Previous message: [Users] so, what do you want next in oVirt? View on lists.ovirt.org Preview by Yahoo ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] disk ordering
Hello.I've noticed issues with inconsistent disk ordering when doing installs from time to time (on VMs with two disks).I came across this post from Itamar from October 2013 where 'disk ordering' is mentioned as a roadmap item: [Users] oVirt Roadmap feature requests - Summary I haven't found anything more when doing searches. Has any work been done on this, or is there a workaround?This is a little annoying. I never run into this issue under Vmware's ESXi. | | | | | | | | | [Users] oVirt Roadmap feature requests - Summary[Users] oVirt Roadmap feature requests - Summary Itamar Heim iheim at redhat.com Sun Oct 6 15:55:33 EDT 2013 Previous message: [Users] so, what do you want next in oVirt? | | | | View on lists.ovirt.org | Preview by Yahoo | | | | | ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] storage offload capability
Thanks Itamar.I heard the other day that NFS v4.2 is supposed to contain server side copy, so it's possible that we might see this kind of support in one of more storage domain available to ovirt at some stage perhaps next year (in Fedora at least).Is this something that Gluster will also likely provide in a subsequent release once we have proper gfapi support? I'd be interested to hear if others on the list are clamouring for server side offload support in some form. From: Itamar Heim To: Paul Jansen ; users Sent: Saturday, 13 December 2014, 2:16 Subject: Re: [ovirt-users] storage offload capability On 11/13/2014 06:09 AM, Paul Jansen wrote: I have an ovirt 3.5 cluster set up with three el7 hosts. Storage is provided by two Fedora 20 machines and the connection is via multipath iscsi. The performance is quite good. The Fedora 20 iscsi targets are using the 'target' (ie: lio) framework, which support the various t.10 scsi offloads. Vmware supports a subset of these called VAAI and Microsoft has a subset called ODX. Cloning is one if the t.10 extensions that the lio target framework supports. I just tried cloning a vm and noticed that during the process there is a lof of traffic over the iscsi interfaces on the Storage Pool Manager host and the iscsi target machine. With proper support for t.10 cloning I shoudn't see any traffic on the isci links (or very minimal traffic) Is there some way to enable the storage offload functionality in Ovirt? If not, is this on the VDSM roadmap? If support were worked in this should be able to be applied to FCP connections as well. The lio target supports these offloads when acting as a Fiber Channel target also. I've asked this sometime back but there hasn't been much in the way of discussion on this users list or the devel list about this feature. yes, on the roadmap, tbd yet on when. netapp did a plugin enabling this for their storage array (VSC plugin) I hope the ceph integration will provide this, though that doesn't solve it for other type of storage domains yet. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] q35 machine support?
SNIP After doing some more searching I came across these two pages: http://www.ovirt.org/Cluster_emulation_modes http://www.ovirt.org/Features/Cluster_parameters_override It sounds like this may allow me to achieve what I've described above. From what I can tell the 'emulated machine type' is tied to the ovirt cluster level - ie: 3.5. you can switch q35 with pc-1.0 in ClusterEmulatedMachines config value for version 3.5 Thanks Paul for asking and Roy for answering. I thought q35 would be the default anyway the whole time ;) engine-config -s ClusterEmulatedMachines=q35,rhel6.5.0 then create a new cluster and add that host to it. once the host is up this emulation mode should be set. in 3.6 you'd be able to choose an emulation mode per VM. Paul, since this is really useful would you mind to open an RFE in BZ and post the link here, so we can keep track of this feature? Hi Daniel. Sorry for the late reply on this. I'm happy that this feature is currently documented in the wiki pages that I'd referenced above and is on the feature plan for 3.6. The workaround that was specified does what I need for now. Proper support in 3.6 will need to consider some other things, such as allowing attaching of disks to the sata interface on the q35 machine. 3.5s current workflow doesn't provide a way to cater for that. Perhaps allowing atachign 'virtio-scsi disks to this interface woudl work fine, but then there's issue with the naming. Additionally, there have been issues reported with live migration of machines that have the ICH9-AHCI controller enabled. Any RFE should handle these multifaceted issues - and others I'm not aware of - so given I don't understand all the ins and outs I'd prefer not to raise this. I'd be interested to hear Sandro's take on how this should likely proceed though.___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] q35 machine support?
Is there a way to get QEMUs q35 machine in Ovirt? I've just upgraded my ovirt 3.4.4 install that has a couple of EL6.5 hosts. If I create a cluster with EL7 or F20 hosts will I get the option to use the q35 machine? If so, how can I select this? Thanks. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] importing a qcow2 disk into ovirt 3.5?
On 21/10/14 02:27, Paul Jansen wrote: I've just been doing some searching to try and work out how to get a vmware windows VM into ovirt. It seems that the newest virtv2v has dropped support for importing from an ESXi standalone machine - and now only works with vcenter. I didn't have any success with using the current virt-v2v attaching to an ESXi host. I've prepared the VM by first removing the vmware tools and have installled the various virtio drivers, as well as running the 'mergeide' registry file to enable IDE. I've used 'qemu-img' to convirt this VMDK file to QCOW2. It does not appear that there is a straightforward way for me to import this new qcow2 disk into ovirt. It seems my best option at the moment is to export the VMware VM as an OVA and then try and use a newer virt-v2v to import this into ovirt. Alternatively I could construct a VM in virt-manager and attach the converted qcow2 disk to it, and then use virt-v2v to import this into ovirt. Can someone suggest an alternative course of action? It seems strange that I can't just import a disk into ovirt, construct a VM and attach the disk. Is there anything int he works to make this process easier? Thanks, Paul Wrote this awhile back as a quick qcow to ovf implementation to import into ovirt-engine/rhevm. There are newer options but this does the job really quick. Will wrap the qcow image into an exploded ova structure or zipped. You can then import it directly into engine with engine-image-uploader. https://jboggs.fedorapeople.org/guest-image-ovf-creator.py Thanks for all the replies with suggestions on how to tackle this. I've tried Joey's script above and it does the trick nicely. Having 'qemu-img', Joey's script referenced above plus engine-image-uploader on a machine allowed me to convert a VMDK file to QCOW2 and then push the resulant QCOW2 disk - wrapped in a basic VM - up to my ovirt export domain. From there I was able to import it as a template, and then create a machine based on that template. This was relatively simple. I'm looking forward to seeing some integration in the oVirt UI that may handle this in future. I have a VMware vcenter installation and often use the 'deploy from OVF template' menu item - which I just pass a http URI with the OVF/OVA and have it deploy a VM on my cluster. This would be great to see in ovirt.___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] q35 machine support?
Cluster emulation modes Contents 1 Cluster emulation mode 1.1 Summary 1.2 Owner 1.3 Current status 1.4 Detailed Description 1.4.1 New Config value 1.4.2 New Host field 1.4.3 New Cluster field 1.4.4 New NON_OPERATIONAL reason View on www.ovirt.org Preview by Yahoo On 23/10/1403:50 , Paul Jansen wrote: Is there a way to get QEMUs q35 machine in Ovirt? I've just upgraded my ovirt 3.4.4 install that has a couple of EL6.5 hosts. If I create a cluster with EL7 or F20 hosts will I get the option to use the q35 machine? If so, how can I select this? Thanks. After doing some more searching I came across these two pages: http://www.ovirt.org/Cluster_emulation_modes http://www.ovirt.org/Features/Cluster_parameters_override It sounds like this may allow me to achieve what I've described above. From what I can tell the 'emulated machine type' is tied to the ovirt cluster level - ie: 3.5. Is it a case of waiting for ovirt 3.6 to be able to override this or is there some other way to achieve this now?___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] q35 machine support?
On 10/23/2014 16:56 PM, Roy Golan wrote: On 10/23/2014 12:13 PM, Paul Jansen wrote: Cluster emulation modes http://www.ovirt.org/Cluster_emulation_modes Contents 1 Cluster emulation mode 1.1 Summary 1.2 Owner 1.3 Current status 1.4 Detailed Description 1.4.1 New Config value 1.4.2 New Host field 1.4.3 New Cluster field 1.4.4 New NON_OPERATIONAL reason View on www.ovirt.org http://www.ovirt.org/Cluster_emulation_modes Preview by Yahoo /On 23/10/14/// 03:50/ , Paul Jansen wrote:/ Is there a way to get QEMUs q35 machine in Ovirt? I've just upgraded my ovirt 3.4.4 install that has a couple of EL6.5 hosts. If I create a cluster with EL7 or F20 hosts will I get the option to use the q35 machine? If so, how can I select this? Thanks. After doing some more searching I came across these two pages: http://www.ovirt.org/Cluster_emulation_modes http://www.ovirt.org/Features/Cluster_parameters_override It sounds like this may allow me to achieve what I've described above. From what I can tell the 'emulated machine type' is tied to the ovirt cluster level - ie: 3.5. you can switch q35 with pc-1.0 in ClusterEmulatedMachines config value for version 3.5 engine-config -s ClusterEmulatedMachines=q35,rhel6.5.0 then create a new cluster and add that host to it. once the host is up this emulation mode should be set. in 3.6 you'd be able to choose an emulation mode per VM. Thanks Roy. I will give this a try, create a new cluster and add a new host to test this out.___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] importing a qcow2 disk into ovirt 3.5?
On 21/10/14 07:27, Paul Jansen wrote: I've just been doing some searching to try and work out how to get a vmware windows VM into ovirt. It seems that the newest virtv2v has dropped support for importing from an ESXi standalone machine - and now only works with vcenter. I didn't have any success with using the current virt-v2v attaching to an ESXi host. I've prepared the VM by first removing the vmware tools and have installled the various virtio drivers, as well as running the 'mergeide' registry file to enable IDE. I've used 'qemu-img' to convirt this VMDK file to QCOW2. It does not appear that there is a straightforward way for me to import this new qcow2 disk into ovirt. It seems my best option at the moment is to export the VMware VM as an OVA and then try and use a newer virt-v2v to import this into ovirt. Alternatively I could construct a VM in virt-manager and attach the converted qcow2 disk to it, and then use virt-v2v to import this into ovirt. Can someone suggest an alternative course of action? It seems strange that I can't just import a disk into ovirt, construct a VM and attach the disk. Is there anything int he works to make this process easier? Did you consult the documentation of virt-v2v ? Imho all the information you need is there, but I didn't test this myself so ymmv. Here's the link: virt-v2v HTH -- Mit freundlichen Grüßen / Regards Sven Kieske virt-v2v NAME SYNOPSIS DESCRIPTION INPUT AND OUTPUT MODES EXAMPLES Convert from VMware vCenter server to local libvirt Convert from ESX to RHEV-M/oVirt Convert disk image to OpenStack glance View on libguestfs.org Preview by Yahoo Hi Sven. Yes, I've had a look at that doco. I've even built up a Centos 7 machine and installed the EL7.1 libguestfs preview, which contains the very recent 1.28 release of libguestfs. I'd be most interested to hear peoples experiences doing these kinds of operations. I remeber Sandro was soliciting feedback about how the import process could be improved not long ago. It seems this is still an area that needs a bit of polish in ovirt - not to take away from the significant work that Richard Jones in doing with libguestfs and the associated tools. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] importing a qcow2 disk into ovirt 3.5?
I've just been doing some searching to try and work out how to get a vmware windows VM into ovirt. It seems that the newest virtv2v has dropped support for importing from an ESXi standalone machine - and now only works with vcenter. I didn't have any success with using the current virt-v2v attaching to an ESXi host. I've prepared the VM by first removing the vmware tools and have installled the various virtio drivers, as well as running the 'mergeide' registry file to enable IDE. I've used 'qemu-img' to convirt this VMDK file to QCOW2. It does not appear that there is a straightforward way for me to import this new qcow2 disk into ovirt. It seems my best option at the moment is to export the VMware VM as an OVA and then try and use a newer virt-v2v to import this into ovirt. Alternatively I could construct a VM in virt-manager and attach the converted qcow2 disk to it, and then use virt-v2v to import this into ovirt. Can someone suggest an alternative course of action? It seems strange that I can't just import a disk into ovirt, construct a VM and attach the disk. Is there anything int he works to make this process easier? Thanks, Paul ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] [RFI] oVirt 3.6 Planning
My vote is for storage load balancing/scheduler. Vmware's Vcenter has the concept of a 'storage cluster'. It's essentially a logical storage device. When you configure hosts/vms to use this device vcenter then works out which of the actual storage devices underneath this logical device is will send the storage requests to. This works out as a basic form of load balacing by alternating where the storage for new vms are created. This isn't particularly amazing, but what it does allow - with the highest end vcenter licensing anyway - is what Vmware calls 'storage distributed resource scheduling'. Much like we already have the ability to have a scheduler that moves the execution of vms around on hosts based on load, this does the same thing for the storage component of VM. Imagine having two configured storage locations under a 'storage cluster' and then having the ability to put one of the storage locations into 'maintenance mode'. The storage scheduler would then 'live storage migrate' all the storage for vms over to the other storage location. This would then allow the first storage location to be taken down for maintenance. This approach also allows storage to scale over time as more is added. The 'storage scheduler' can take inputs such as latency etc into account and manage the load across the 'storage cluster' to balance things out and make smart decisions so that the avaialble storage is utilized as best as it can be (ie: not overloading one storage location while the other location is mainly idle). I've done a bit a searching to see where Ovirt might be up to in this regard and what I've found seems to indicate that we are not anywhere near this capability just yet. An important prerequisite is having the hosts able to actually do a live storage migration. EL7 based hosts under ovirt 3.5 have this, as have Fedora 19 and 20 hosts. If the decision is made to use qemu-kvm-rhev on EL6 hosts - as has been talked about recently - then the host requirement for supporting live storage migration will be met. This then allows the idea of a storage scheduler to be futher considered. I think this is an important step in reaching feature parity with Vmware's vcenter product, and removes a key reason ovirt/rhev can't be considered in some instances. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] vm install via iso - optical drive eject behaviour?
Hello. I currently have oVirt 3.4.x set up. A colleague mentioned that he was having an issue where booting a VM with an attached iso and installing via cd/dvd does not allow the contents of the 'drive' to eject after the install. Sure enough, I have tested this myself and observed the same behaviour. Installing an EL/fedora iso image with a kickstart that has a 'reboot --eject' line in will eject the 'drive' after the installing when doing the exact same thing on VMware ESXi (and 'real' hardware). A suggestion was made that VMware emulates a laptop style optical drive that once the disk ejects the system cannot close the drive bay upon reboot - this is a manual operation. Does oVirt emulate a destop style drive where even if the disk is ejected, when a reboot occurs the drive will close? The long an short of this that even though the 'reboot --eject' option is in the kickstart, the iso image seems be be reattached when the VM reboots and the installs process starts again. An infinite loop effectively. I'm told this isn't an issue with an KVM/Qemu VM under virt-manager. Any suggestions as to how to solve this? I should point out that I cannot simply extract files and boot via PXE as this process is supposed to be testing an install process via generated media. Thanks. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] el7 hosts? el7 node iso?
I see from here - https://fedorahosted.org/ovirt/ticket/123 - that vdsm is now building OK on el7. What are the plans for el7 and oVirt 3.5? I seem to recall hearing that there was a hope that there would be some initial support by the time oVirt 3,5 release comes around. I understand that there are functional tests for vdsm, but that these tests are not complete. Are these tests running on an el7 jenkins slave at this point? Is there likely to be an el7 node iso spin in the near future? I'm super keen to know whether live snapshots/storage migration works with oVirt 3.5 and el7 hosts. Has anyone got any info?___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] 1009100 likely be be fixed for 3.5.0?
Hello. There are a few bugs that are related to live snapshots/storage migrations not working. https://bugzilla.redhat.com/show_bug.cgi?id=1009100 is one of them and is targeted for 3.5.0. According to the bug there is some engine work still required. I understand that with EL6 based hosts live storage migration will still not work (due to a too old QEMU version), but it should work with F20/21 hosts (and EL7 hosts when that comes online). Am I correct in assuming that in a cluster with both EL6 hosts and new hosts (described above) that ovirt will allow live storage migration on hosts that support it and prevent the option from appearing on hosts that do not? The possibility of getting a newer QEMU on EL6 appears to be tied up in the Centos virt SIG and their proposed repository, which appears to be moving quite slowly. I'm looking forward to ovirt closing the gap to vmware vcenter in regard to live storage migrations. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] qemu-kvm-rhev for el6
hello, does anyone know if there are an existent bugzilla to track the release of qemu-kvm-rhev rpms under el (like centos)? Because I've looked at bugzilla and google docs oVirt Planning Tracking with no luck best regards a I think this is the best fit that I have found so far: https://bugzilla.redhat.com/show_bug.cgi?id=1009100 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] node spin including qemu-kvm-rhev?
- Original Message - From: Paul Jansen To: Itamar Heim Fabian Deutsch Cc: users Sent: Monday, April 7, 2014 3:25:19 PM Subject: Re: [Users] node spin including qemu-kvm-rhev? On 04/07/2014 11:46 AM, Fabian Deutsch wrote: Hey Paul, Am Montag, den 07.04.2014, 01:28 -0700 schrieb Paul Jansen: I'm going to try top posting this time to see if it ends up looking a bit better on the list. you could try sending text-only emails :) By the 'ovirt hypervisor packages' I meant installing the OS first of all and then making it into an ovirt 'node' by installing the required packages, rather than installing from a clean slate with the ovirt node iso. Sorry if that was a bit unclear. Okay - thanks for the explanation. In general I would discourage from installing the ovirt-node package ona normal host. If you still want to try it be aware that the ovirt-node pkg might mess with your system. I'm pretty sure we are on the same page here. I just checked the ovirt 'quickstart' page and it calls the various hypervisor nodes 'hosts'. ie: Fedora host, EL, host, ovirt node host. If the ovirt node included the qemu-kvm-rhev package - or an updated qemu-kvm - it would mean that both ovirt node hosts and fedora hosts could both support live storage migration. It would only be EL hosts that do not support that feature at this stage. We could have a caveat in the documentation for this perhaps. Fabian, were you think thinking that if not all 'hosts' supported live migration that the cluster could disable that feature? Based on capabilities that the hosts would expose to the ovirt server? This would be another way of avoiding the confusion. Thanks guys for the great work you are doing with ovirt. Paul, this is something that vdsm needs to report to the engine, so the engine will know what is / isn't supported. It's a bigger request as today we're mostly based on cluster compatibility level. Additionally it is possible to mix .el hosts with nodes with old (non -rhev) nodes. Each of these cases will break live-storage migration. How do you suggest to mitigate it? Well, when you choose to migrate a VM under Vmware's Vcenter you can choose to migrate either the host or the datastore. For whichever one you choose there is a validation step to check the you are able to perform the migration (ie: capabilities of the host). I can see in ovirt that we are showing the KVM version on hosts. This matches the package version of the qemu-kvm package (or the qemu-kvm-rhev package if installed?). Could we have some sort of a cutoff point where we know which versions of KVM (ie: qemu-kvm or qemu-kvm-rhev) support the storage migration feature, and if a version is found that doesn't match the required heuristics we just indicate the the validation process for the migration has failed? We could provide some small output indicating why it has failed. Does this sound like a reasonable approach? Is there any news on discussions with the CentOS people as to where a qemu-kvm-rhev package could be hosted (that we could then take advantage of)? If the hosting of an updated qemu-kvm (or qemu-kvm-rhev) is not sorted out in the short term, I did some quick calculations last night and it seems based on previous EL point releases (this is hardly scientific I know) we are not likely to see an EL 6.6 for another few months. We may see an EL7.0 before that timeframe. Ovirt can obviously jump on new EL releases to use as hosts in a new ovirt version but it seems this option is still some time away. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] node spin including qemu-kvm-rhev?
I'm going to try top posting this time to see if it ends up looking a bit better on the list. By the 'ovirt hypervisor packages' I meant installing the OS first of all and then making it into an ovirt 'node' by installing the required packages, rather than installing from a clean slate with the ovirt node iso. Sorry if that was a bit unclear. From: Fabian Deutsch To: Paul Jansen Cc: Doron Fediuck; users Sent: Monday, 7 April 2014 5:20 PM Subject: Re: [Users] node spin including qemu-kvm-rhev? Am Sonntag, den 06.04.2014, 19:15 -0700 schrieb Paul Jansen: My mail client might mangle the bottom-posting here, so we'll see how it goes. I saw a post from Fabian that he had re-enabled jenkins builds of the node image based on Fedora 19/20 (but not yet including the VDSM plugin). Presumably the main goal of this is to ensure that things in node land are OK for an upcoming spin based on EL7? EL7 is one point, but there were users also asking for Fedora based Nodes and we use Fedora for development, to have stable Nodes (at some point later) based on CentOS. If ovirt does go back to having Fedora and EL based node images in the short term it would mean that live migration will work on the Fedora images. The Fedora based images are at least for now available from Jenkins. If it was also decided to allow the EL based node image to include the recompiled qemu-kvm-rhev package the Ovirt release notes could then say that when using an ovirt node image live migration is supported, as is when a fedora install has the ovirt hypervisor packages installed. What is this ovirt hypervisor package you mention? - fabian It would only be that an EL based system - built up to then also include the ovirt hypervisor packages - that live migration would not be supported - at this stage. This can change when the details are further worked out with the Centos people about how the updated qemu-kvm packages will be hosted and made available. In the meantime, people that want to set things up so that live migration is there can do so. Once live migration is in place I think it would be interesting to try and find out from people interested (or already testing ovirt) that have VMware backgrounds/experience what they think is the the largest outstanding issue feature wise when comparing ovirt to Vcenter. What would stop them from migrating from vcenter to ovirt?___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] node spin including qemu-kvm-rhev?
On 04/07/2014 11:46 AM, Fabian Deutsch wrote: Hey Paul, Am Montag, den 07.04.2014, 01:28 -0700 schrieb Paul Jansen: I'm going to try top posting this time to see if it ends up looking a bit better on the list. you could try sending text-only emails :) By the 'ovirt hypervisor packages' I meant installing the OS first of all and then making it into an ovirt 'node' by installing the required packages, rather than installing from a clean slate with the ovirt node iso. Sorry if that was a bit unclear. Okay - thanks for the explanation. In general I would discourage from installing the ovirt-node package ona normal host. If you still want to try it be aware that the ovirt-node pkg might mess with your system. I'm pretty sure we are on the same page here. I just checked the ovirt 'quickstart' page and it calls the various hypervisor nodes 'hosts'. ie: Fedora host, EL, host, ovirt node host. If the ovirt node included the qemu-kvm-rhev package - or an updated qemu-kvm - it would mean that both ovirt node hosts and fedora hosts could both support live storage migration. It would only be EL hosts that do not support that feature at this stage. We could have a caveat in the documentation for this perhaps. Fabian, were you think thinking that if not all 'hosts' supported live migration that the cluster could disable that feature? Based on capabilities that the hosts would expose to the ovirt server? This would be another way of avoiding the confusion. Thanks guys for the great work you are doing with ovirt. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] node spin including qemu-kvm-rhev?
- Original Message - From: Paul Jansen vla...@yahoo.com.au To: users users@ovirt.org Sent: Wednesday, April 2, 2014 11:38:29 AM Subject: [Users] node spin including qemu-kvm-rhev? I understand that there are ongoing discussions with the Centos people regarding a suitable home for recompiled qemu-kvm packages. Given that the ovirt node is our own spin, is there any reason why that couldn't include the recompiled qemu-kvm packages that will then allow us to use live snapshots and do live migrations? Itamar recently mentioned that we already build these via a jenkins task. Nodes built on top of a Centos install will still be an issue but I think its reasonable that the ovirt-node iso could include these custom packages. This way we don't have to potentially wait until 3.4.1 or 3.5 to get the live snapshot/migration features. The caveat would be that these features would only be supported if the nodes were all ovirt node iso based. What are people's thoughts? Sounds reasonable as long as you understand mix and match will become an issue. The questions is how do we differentiate between the nodes to make sure no one mixes them by mistake? My mail client might mangle the bottom-posting here, so we'll see how it goes. I saw a post from Fabian that he had re-enabled jenkins builds of the node image based on Fedora 19/20 (but not yet including the VDSM plugin). Presumably the main goal of this is to ensure that things in node land are OK for an upcoming spin based on EL7? If ovirt does go back to having Fedora and EL based node images in the short term it would mean that live migration will work on the Fedora images. If it was also decided to allow the EL based node image to include the recompiled qemu-kvm-rhev package the Ovirt release notes could then say that when using an ovirt node image live migration is supported, as is when a fedora install has the ovirt hypervisor packages installed. It would only be that an EL based system - built up to then also include the ovirt hypervisor packages - that live migration would not be supported - at this stage. This can change when the details are further worked out with the Centos people about how the updated qemu-kvm packages will be hosted and made available. In the meantime, people that want to set things up so that live migration is there can do so. Once live migration is in place I think it would be interesting to try and find out from people interested (or already testing ovirt) that have VMware backgrounds/experience what they think is the the largest outstanding issue feature wise when comparing ovirt to Vcenter. What would stop them from migrating from vcenter to ovirt? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] el7 based node? el7 as a supported platform for ovirt?
Hi. There's been a bit of chatter about what is required for Fedora 20 support for ovirt. I can't seem to find newer fedora19 based node isos anymore. Has there been a conscious decision to standardize on the el6 based node iso? Is an F20 based node iso something that is being worked on? I hear that el7 might be announced this month. Presumably Centos 7.0 won't be far away after that. I've done some test installs of RHEL 7 beta to get a look at what packages are in use. Of particular interest to me is the qemu-kvm package - the version of which seem to be important for live snapshots and live migrations (something we don't seem to do well right now). EL beta7 has this version - qemu-kvm-1.5.3-19.el7.x86_64.rpm Given the issues with needing newer versions of certain packages than what is in EL 6.5, is this situation likely to be improved greatly when Centos 7 is available? I don't recall seeing much discussion about ovirt running under el7. Is this being looked at at this stage, or given the fact there is only a beta of rhel7 to work with right now are we just waiting for the release before deciding too much? Thanks. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] node spin including qemu-kvm-rhev?
I understand that there are ongoing discussions with the Centos people regarding a suitable home for recompiled qemu-kvm packages. Given that the ovirt node is our own spin, is there any reason why that couldn't include the recompiled qemu-kvm packages that will then allow us to use live snapshots and do live migrations? Itamar recently mentioned that we already build these via a jenkins task. Nodes built on top of a Centos install will still be an issue but I think its reasonable that the ovirt-node iso could include these custom packages. This way we don't have to potentially wait until 3.4.1 or 3.5 to get the live snapshot/migration features. The caveat would be that these features would only be supported if the nodes were all ovirt node iso based. What are people's thoughts? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] live storage migration - when is this being targeted?
From what I can understand ovirt 3.4.0 - or a least the hypervisor part based on el6 - cannot do live storage migration due to an older qemu-kvm package. I assume this is a related bug? https://bugzilla.redhat.com/show_bug.cgi?id=1009100 From what I can infer from this there is a related issue with vdsm that needs handling as well? From a feature parity perspective against Vmware Vcenter (Enterprise plus) this is a very important feature. I can think of a number of Vmware shops that wouldn't look an a competing hypervisor management platform without this feature working. I think this would be a key milestone for ovirt to get to. Is this something that is likely to be worked out for the 3.4.1 timeframe or is it now a 3.5 issue? Thanks. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt Node 3.0.3-1 for oVirt 3.3 release
Hi Nauman. I wasn't able to get back and do further debugging on this just yet. I have been hoping that Fabian will release new node isos based on EL6.5 and Fedora 20 that might mean the issue I ran into somehow went away. Unfortunately no new isos are available yet as far as I can see. I will try and go through the troubleshooting process to get the information into bugzilla in the next week or so though. On Monday, 6 January 2014 6:28 PM, Nauman Abbas nauman.ab...@seecs.edu.pk wrote: Hello there Did you find a solution to this problem you mentioned on oVirt list few days ago since I'm facing the same now. http://lists.ovirt.org/pipermail/users/2013-December/018323.html Regards Nauman Abbas Assistant System Administrator (LMS), Room No. A-207, SEECS, National University of Sciences Technology, + 92 321 5359946___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt Node 3.0.3-1 for oVirt 3.3 release
Replying to my own message here.
I've just tried to install this latest oVirt node image again and made notes
where it fell over.
At the 'Keyboard layout selection' screen I press enter to select the default
'US English' option.
After a few seconds delay I then get this error screen:
An exception occurred
'other'
close
After pressing close I'm then back at the 'Keyboard layout selection' screen.
If I then press enter on 'US international' then tab down to the option to
continue I can make my way to the screen where I have to enter the password for
the admin user. After continuing from there I immediately get an error on the
install progress screen - at the 40% point.
The error reads:
Exception:
Value Error ('invalid literal for int() with base10: '',)
reboot
I just tried another install and this time selected 'US International' first
time from the 'Keyboard layout selection' screen.
On Friday, 29 November 2013 10:57 PM, Paul Jansen vla...@yahoo.com.au wrote:
Fabian,
I've downloaded the
ovirt-node-iso-3.0.3-1.1.vdsm.fc19.iso image and have tried installing it on
two separate machines.
Whether I do a regular install (default boot screen option) or choose
'reinstall' from the troubleshooting menu I get tripped up at the same spot.
When it comes time to select a keyboard layout (I think this is correct) US
English is the default. I press enter at that point and after a short delay
there is a very uninformative error message that appears. I can't remember
what it is off the top of my head and the systems are at work (I'm at home now).
After this point I can continue but the install fails immediately after I get
past the install target selection screen.
Has anyone successfully installed a node using this iso image?
I even tried removing partitions from the drive beforehand, to the point of
dd'ing the first 512 bytes to make sure there was no partition table.
This didn't help - I still ran into the install error described above.
I particularly wanted to try an FC19 based node to try out live storage
migration on NFS, as I was having problems with the EL6.4 node with this.
Is there a chance that that issue might be resolved for EL6 based nodes by an
upcoming new EL6.5 based node spin?
Sorry I cannot provide the exact error details for the install issue now, but I
can get the error detail in the next couple of days if required.
Thanks,
Paul
This time the install seems to work.
Unfortunately when it comes up the SSH service doesn't seem to be working.
When I try and ssh to the machine I get the following:
Read from socket failed: Connection reset by peer
The above was after configuring the node for an Ovirt engine, accepting the
certificate and entering a password.
The ovirt web GUI shows this node as non responsive.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt Node 3.0.3-1 for oVirt 3.3 release
Fabian, I've downloaded the ovirt-node-iso-3.0.3-1.1.vdsm.fc19.iso image and have tried installing it on two separate machines. Whether I do a regular install (default boot screen option) or choose 'reinstall' from the troubleshooting menu I get tripped up at the same spot. When it comes time to select a keyboard layout (I think this is correct) US English is the default. I press enter at that point and after a short delay there is a very uninformative error message that appears. I can't remember what it is off the top of my head and the systems are at work (I'm at home now). After this point I can continue but the install fails immediately after I get past the install target selection screen. Has anyone successfully installed a node using this iso image? I even tried removing partitions from the drive beforehand, to the point of dd'ing the first 512 bytes to make sure there was no partition table. This didn't help - I still ran into the install error described above. I particularly wanted to try an FC19 based node to try out live storage migration on NFS, as I was having problems with the EL6.4 node with this. Is there a chance that that issue might be resolved for EL6 based nodes by an upcoming new EL6.5 based node spin? Sorry I cannot provide the exact error details for the install issue now, but I can get the error detail in the next couple of days if required. Thanks, Paul ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] 3.3.1 node isos?
Are the 3.3.1 node isos that Fabian mentionedlate last week available for download yet? I've had a look around resources.ovirt.org but can't see anything yet. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] EL5 support for VirtIO SCSI?
Hello Stefan. Thanks. I understand qemu supports other scsi adapters however. See this post from earlier this year. That post makes reference to the following hbas: auto, buslogic, ibmvscsi. lsilogic, lsisas1068, lsisas1078, virtio-scsi, vmpvscsi. The post is referring to libvirt, so the number of adapters may be related to the various virtualization backends that libvirt can interface with. There are numerous references to qemu/qemu-kvm supporting other scsi adapters as well as AHCI SATA. I installed the Centos 6.4 based node, so perhaps the Fedora 19 based node has a newer qemu that supports more of these features? I might see if I can do an install of the Fedora 19 based node tomorrow. Ayal mentioned using 'hooks' to interface with qemu to possibly create a VM outside of the definitions that Ovirt allows. If I am understanding this correctly - how do I do this? Am I to expect some interface inconsistencies in the ovirt portal I I view a 'custom' VM like this? So, in short - is there the potential for me to create a VM in ovirt that has a SCSI/SAS/SATA HBA and attach disk(s) to it (other than the virtio-scsi HBA which is not supported under EL5)? On Thursday, 14 November 2013 11:22 PM, Stefan Hajnoczi stefa...@redhat.com wrote: On Thu, Nov 14, 2013 at 02:39:33AM -0500, Ayal Baron wrote: - Original Message - Hello Itamar. The specific use case is a particular propriety filesystem that needs to see a scsi device. It will do scsi inquiry conmmands to verify suitability. In talking to the devs - of the filesystem - there is no way around it. I'd previously tried virtio-block - resulting in the /dev/vd* device - and the filesystem would not work. From doing a bit of web searching it appears the kvm/qemu supports (or did support) an emulated LSI scsi controller. My understanding is that the various virtualization platforms will emulate a well supported device (by the guest OSes) so that drivers are not an issue. For example this should allow a VM on Vmware vsphere/vcenter to be exported to Ovirt and have it boot up. The potential for further optimising the guest is there by installing ovirt/qemu/kvm guest utils that then allow the guest OS to understand the virtio nic and scsi devices. The guest could then be shut down, the nic and scsi controller changed and the guest booted up again. You can do the same thing in the Vmware world by installing their guest tools, shutting down the guest VM, then reconfiguring it with a vmxnet3 nic and pvscsi scsi adapter, then booting up again. It does seem somewhat inconsistent in Ovirt that we allow a choice of Intel e1000 or virtio nics, but do not offer any choice with the scsi adapter. virtio-scsi support was just recently added to oVirt to allow for scsi passthrough and improved performance over virtio-blk. I believe the emulated scsi device in qemu never matured enough but possibly Stefan (cc'd) can correct me here. The only supported emulated SCSI HBA device is virtio-scsi. It was Tech Preview in RHEL 6.3 and became fully supported in RHEL 6.4. virtio-scsi is not available in RHEL 5. Stefan___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] EL5 support for VirtIO SCSI?
Hi Rene. I specifically need the scsi support (virtio-scsi). I do know about the virtio-block support, which results in /dev/vd* devices as you say. From what I read even EL6 earlier than 6.3 does not support virtio-scsi Alternatively, does oVirt support an emulated scsi adapter of a different type that would allow me to see scsi disks? Regards, Paul On Wednesday, 13 November 2013 7:23 PM, René Koch (ovido) r.k...@ovido.at wrote: On Wed, 2013-11-13 at 09:41 +0100, Sander Grendelman wrote: According to https://access.redhat.com/site/solutions/20511 virtio work on rhel5.3. You have to edit /etc/modprobe.conf and generate a new initrd. If you're installing the OS on a VirtIO disk this is done automatically by anaconda. I just installed RHEL 5 on oVirt 3.3 with VirtIO disk and everything worked out of the box. On Wed, Nov 13, 2013 at 9:32 AM, Sven Kieske s.kie...@mittwald.de wrote: Hi, afaik the rhel 5 kernel series just has not the necessary drivers for all virtio stuff, so it's not supported and does not work, unless you want to patch your own kernel. Am 13.11.2013 06:44, schrieb Paul Jansen: I have just set up an Ovirt 3.3.0 install and have done a test install of Centos 6.4 in a VM. The VM was configured with an IDE drive and a virtio-scsi drive. The Centos 6.4 install sees both drives OK. I'm wanting to do some testing on a product that is based on EL5, but I'm finding that it cannot see the virtio-scsi drive. It does show up in the output of 'lspci', but I don't see a corresponding 'sd' device. There's no /dev/sd* device - the devices are named /dev/vd*... I've just tried installing Centos 5.10 and the support is not there. Didn't test CentOS but RHEL 5 is working fine. Regards, René Does anyone know of any tricks to allow EL5 to see the virtio-scsi device? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] EL5 support for VirtIO SCSI?
I have just set up an Ovirt 3.3.0 install and have done a test install of Centos 6.4 in a VM. The VM was configured with an IDE drive and a virtio-scsi drive. The Centos 6.4 install sees both drives OK. I'm wanting to do some testing on a product that is based on EL5, but I'm finding that it cannot see the virtio-scsi drive. It does show up in the output of 'lspci', but I don't see a corresponding 'sd' device. I've just tried installing Centos 5.10 and the support is not there. Does anyone know of any tricks to allow EL5 to see the virtio-scsi device?___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] Support for VAAI SCSI primitives in ovirt?
Hello. I've been following the progress of VAAI support being added to the 'target-core' framework in the Linux kernel. Support for all 4 features did not make it into the recent 3.11 kernel release but is planned for 3.12. There is some detail on VAAI (Vsphere APIs for Array Integration) here. VAAI is obviously a VMware term, but the SCSI primitives it refers to are open. From the above linked page: VAAI significantly enhances the integration of storage and servers by enabling seamless offload of locking and block operations onto the storage array. It seems reasonable to assume that Fedora 20 (and probably Fedora 19 with a kernel update at some stage) will be using the 3.12 kernel and could be used to export iSCSI/FC targets to Ovirt. VMware also provides VAAI integration for NAS datastores (via the installation of a vendor specific plugin into Vmware Vcenter) that also significantly improves performance for some operations. From what I can make out from the VMware documentation the ability to use the VAAI offloads only applies to the upper tier licensed version of vcenter. I think there is an opportunity for Ovirt to add support for this feature and make it stand out even against the freely licensed ESXi (which will be missing this feature). With more people looking to Ovirt rather than getting started and potentially staying with VMware this is a good opportunity to gather market share. What is the current status of support for these VAAI scsi primitives in Ovirt? Is there anything planned at the moment? Regarding the VAAI NAS plugin feature that VMware now has - are there plans to help offload certain operations happening on NFS datastores? For instance some sort of agent that can be installed on a Linux NFS server could allow oVirt to instruct the NFS server machine to perform an offloaded copy/clone operation rather than that process needing to be done over the wire. Thanks, Paul ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] scsi disks inside VMs?
Hello. I'm wondering if it is possible to create VMs with ovirt that have scsi disks? I've just installed ovirt 3.2.1 on Fedora 18 and attached an ovirt node (the current fedora 18 based version). When adding disks to a VM I can chose from the 'IDE' or 'VirtIO' interfaces. I'd like a scsi option also. Mainly because when migrating from vsphere VMs this makes things simpler. Also, my current kickstart installer for various OSes does not yet handle 'vd' disks. To add to things I need to install a custom filesystem on the vms that wants a scsi disk. It does a scsi inquiry early on in the install phase and will not work in 'vd' disks. ie: 'sg_inq /dev/vda' does not work. I also know that the libata driver in recent linux distributions exposes IDE drives as scsi and allows a scsi enquiry to succeed. Unfortunately the use case I have required Enterprise Linux 5 and in this release IDE disks report as 'hd', whereas scsi disks report as 'sd'. So, I can just use an IDE disk to get around this problem. I understand that virt-manager will allow attaching scsi disks to KVM based virtual machines, and that this is made possible by recent changes in libvirt. I think we should be encouraging people to use the virtio disks where possible, but in cases where this is not straightforward ovirt - and RHEV - are missing a trick as far as allowing people that have existing vsphere setups to fairly easily move to ovirt. Is a 'scsi' interface' option for adding virtual disks for VMs on the roadmap? If not, could it be considered? Thanks. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
