cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: Review Request 14381: KVM: add connect/disconnect capabilities to StorageAdaptors so that external storage services can attach/detach devices on-demand
Date Sat, 26 Oct 2013 05:23:16 GMT
I usually pick Linux (32-bit) and must have forgot to make a selection.

On a side note, a good usability change would be to start with nothing
selected and require the user to choose an OS. :)


On Fri, Oct 25, 2013 at 11:22 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> Doh! I picked the wrong OS! :)
>
>
> On Fri, Oct 25, 2013 at 11:22 PM, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
>
>> <domain type='kvm' id='13'>
>>   <name>i-2-8-VM</name>
>>   <uuid>2d0a4f06-f0df-4c69-90c2-1e0b91871ad7</uuid>
>>   <description>Apple Mac OS X 10.6 (32-bit)</description>
>>   <memory>262144</memory>
>>   <currentMemory>262144</currentMemory>
>>   <vcpu>1</vcpu>
>>   <cputune>
>>     <shares>500</shares>
>>   </cputune>
>>   <os>
>>     <type arch='x86_64' machine='pc-1.0'>hvm</type>
>>     <boot dev='cdrom'/>
>>     <boot dev='hd'/>
>>   </os>
>>   <features>
>>     <acpi/>
>>     <apic/>
>>     <pae/>
>>   </features>
>>   <clock offset='utc'/>
>>   <on_poweroff>destroy</on_poweroff>
>>   <on_reboot>restart</on_reboot>
>>   <on_crash>destroy</on_crash>
>>   <devices>
>>     <emulator>/usr/bin/kvm</emulator>
>>     <disk type='file' device='disk'>
>>       <driver name='qemu' type='qcow2' cache='none'/>
>>       <source
>> file='/var/lib/libvirt/images/5a800310-9bba-4d57-8858-728a35034adf'/>
>>       <target dev='hda' bus='ide'/>
>>       <alias name='ide0-0-0'/>
>>       <address type='drive' controller='0' bus='0' unit='0'/>
>>     </disk>
>>     <disk type='block' device='disk'>
>>       <driver name='qemu' type='raw' cache='none'/>
>>       <source
>> dev='/dev/disk/by-path/ip-192.168.233.10:3260-iscsi-iqn.2012-03.com.solidfire:volume1-lun-0'/>
>>       <target dev='hdb' bus='ide'/>
>>       <alias name='ide0-0-1'/>
>>       <address type='drive' controller='0' bus='0' unit='1'/>
>>     </disk>
>>     <disk type='file' device='cdrom'>
>>       <driver name='qemu' type='raw' cache='none'/>
>>       <target dev='hdc' bus='ide'/>
>>       <readonly/>
>>       <alias name='ide0-1-0'/>
>>       <address type='drive' controller='0' bus='1' unit='0'/>
>>     </disk>
>>     <controller type='ide' index='0'>
>>       <alias name='ide0'/>
>>       <address type='pci' domain='0x0000' bus='0x00' slot='0x01'
>> function='0x1'/>
>>     </controller>
>>     <interface type='bridge'>
>>       <mac address='06:5c:52:00:00:18'/>
>>       <source bridge='cloudbr0'/>
>>       <target dev='vnet9'/>
>>       <model type='e1000'/>
>>       <bandwidth>
>>         <inbound average='25600' peak='25600'/>
>>         <outbound average='25600' peak='25600'/>
>>       </bandwidth>
>>       <alias name='net0'/>
>>       <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
>> function='0x0'/>
>>     </interface>
>>     <serial type='pty'>
>>       <source path='/dev/pts/5'/>
>>       <target port='0'/>
>>       <alias name='serial0'/>
>>     </serial>
>>     <console type='pty' tty='/dev/pts/5'>
>>       <source path='/dev/pts/5'/>
>>       <target type='serial' port='0'/>
>>       <alias name='serial0'/>
>>     </console>
>>     <input type='tablet' bus='usb'>
>>       <alias name='input0'/>
>>     </input>
>>     <input type='mouse' bus='ps2'/>
>>     <graphics type='vnc' port='5903' autoport='yes'
>> listen='192.168.233.10'>
>>       <listen type='address' address='192.168.233.10'/>
>>     </graphics>
>>     <video>
>>       <model type='cirrus' vram='9216' heads='1'/>
>>       <alias name='video0'/>
>>       <address type='pci' domain='0x0000' bus='0x00' slot='0x02'
>> function='0x0'/>
>>     </video>
>>     <memballoon model='virtio'>
>>       <alias name='balloon0'/>
>>       <address type='pci' domain='0x0000' bus='0x00' slot='0x04'
>> function='0x0'/>
>>     </memballoon>
>>   </devices>
>> </domain>
>>
>>
>> On Fri, Oct 25, 2013 at 11:20 PM, Mike Tutkowski <
>> mike.tutkowski@solidfire.com> wrote:
>>
>>> Oh, I see. That makes sense. I think I picked Linux (32 bit).
>>>
>>>
>>> On Fri, Oct 25, 2013 at 11:18 PM, Marcus Sorensen <shadowsor@gmail.com>wrote:
>>>
>>>> Do 'virsh dumpxml (vmname)'
>>>>
>>>> The image doesn't matter. What matters is the OS you chose when you
>>>> registered. If you take my image and register it as Windows, it will
>>>> emulate IDE.
>>>> On Oct 25, 2013 11:16 PM, "Mike Tutkowski" <
>>>> mike.tutkowski@solidfire.com> wrote:
>>>>
>>>>> Yeah, I'm using the CentOS 6.3 image you gave me a while back.
>>>>>
>>>>> Is the DiskDef XML output to agent.log or should I explicitly put in a
>>>>> log statement for it.
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>> On Fri, Oct 25, 2013 at 11:02 PM, Marcus Sorensen <shadowsor@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Sounds like your disk definition is not using virtio-block. In this
>>>>>> case you wouldnt be able to hot attach either though. Can you paste the
>>>>>> diskdef XML? This would normally only happen if you used a template defined
>>>>>> with an older OS, like the default centos 5.5 or "other Linux" instead of
>>>>>> "other Linux PV". In those cases I think it emulates IDE, which can't be
>>>>>> hotswapped.
>>>>>> On Oct 25, 2013 10:05 PM, "Mike Tutkowski" <
>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>
>>>>>>> Hey Marcus,
>>>>>>>
>>>>>>> I've been running all sorts of tests today and just noticed one
>>>>>>> issue.
>>>>>>>
>>>>>>> When I have a disk attached and reset (not reboot) the VM, the VM
>>>>>>> comes up just fine.
>>>>>>>
>>>>>>> If I then try to detach the disk, I get the following error:
>>>>>>>
>>>>>>> com.cloud.utils.exception.CloudRuntimeException: Failed to detach
>>>>>>> volume: Vol-6 from VM: VM-KVM-1; org.libvirt.LibvirtException: unsupported
>>>>>>> configuration: This type of disk cannot be hot unplugged
>>>>>>>
>>>>>>> Normally I have no problem detaching a disk. Once I get into this
>>>>>>> state; however, I seem to be stuck with an attached disk.
>>>>>>>
>>>>>>> Any thoughts on this?
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 25, 2013 at 12:58 AM, Mike Tutkowski <
>>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>>
>>>>>>>> Excellent - thanks!
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Oct 25, 2013 at 12:10 AM, Marcus Sorensen <
>>>>>>>> shadowsor@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> tests passed with latest commit hash you sent.
>>>>>>>>>
>>>>>>>>> On Thu, Oct 24, 2013 at 10:10 PM, Mike Tutkowski
>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> > Just playing around with this on XenServer now.
>>>>>>>>> >
>>>>>>>>> > When I stop a VM, XenCenter no longer shows the VM (i.e. it
>>>>>>>>> behaves like VMM
>>>>>>>>> > does when a VM is stopped).
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > On Thu, Oct 24, 2013 at 9:53 PM, Marcus Sorensen <
>>>>>>>>> shadowsor@gmail.com>
>>>>>>>>> > wrote:
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> On Oct 24, 2013 7:39 PM, "Mike Tutkowski" <
>>>>>>>>> mike.tutkowski@solidfire.com>
>>>>>>>>> >> wrote:
>>>>>>>>> >> >
>>>>>>>>> >> > But what happens when, say, XenServer crashes and knows about
>>>>>>>>> VMs it had
>>>>>>>>> >> > running before it crashed?
>>>>>>>>> >>
>>>>>>>>> >> Not sure what XenCenter does but I thought it would/could start
>>>>>>>>> them on
>>>>>>>>> >> other nodes.
>>>>>>>>> >> >
>>>>>>>>> >> > I guess I was thinking you meant that CS purposefully creates
>>>>>>>>> VMs on KVM
>>>>>>>>> >> > in such a fashion that KVM will not remember them in the
>>>>>>>>> event of a crash.
>>>>>>>>> >>
>>>>>>>>> >> You're right about that, you get what I mean. Its done since
>>>>>>>>> there's no
>>>>>>>>> >> central manager and it causes problems for each host to keep a
>>>>>>>>> local config.
>>>>>>>>> >> I meant that CS doesn't necessarily tell the other hypervisors
>>>>>>>>> to remember,
>>>>>>>>> >> per se. They just do because its working through a cluster
>>>>>>>>> manager and
>>>>>>>>> >> that's what they do.
>>>>>>>>> >>
>>>>>>>>> >> >
>>>>>>>>> >> >
>>>>>>>>> >> > On Thu, Oct 24, 2013 at 7:25 PM, Marcus Sorensen <
>>>>>>>>> shadowsor@gmail.com>
>>>>>>>>> >> > wrote:
>>>>>>>>> >> >>
>>>>>>>>> >> >> I just mean that they're still visible on those platforms
>>>>>>>>> because
>>>>>>>>> >> >> they're being tracked by some central source outside of
>>>>>>>>> cloudstack.
>>>>>>>>> >> >> Cloudstack itself I don't think cares, it just manages the
>>>>>>>>> resources as it
>>>>>>>>> >> >> sees in ITs database. I don't really see it as cloudstack
>>>>>>>>> treating KVM
>>>>>>>>> >> >> differently, rather just KVM lacking a central authority or
>>>>>>>>> cluster manager.
>>>>>>>>> >> >>
>>>>>>>>> >> >> On Oct 24, 2013 7:19 PM, "Mike Tutkowski"
>>>>>>>>> >> >> <mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>
>>>>>>>>> >> >>> So, I guess the moral is CloudStack has KVM treat VMs
>>>>>>>>> ephemerally, but
>>>>>>>>> >> >>> we (you and I) don't know how CS has XenServer and VMware
>>>>>>>>> treat VMs.
>>>>>>>>> >> >>>
>>>>>>>>> >> >>> I plan to do some testing with XenServer and VMware in a
>>>>>>>>> bit, so I can
>>>>>>>>> >> >>> stop a VM and see if it remains visible in their GUIs.
>>>>>>>>> >> >>>
>>>>>>>>> >> >>>
>>>>>>>>> >> >>> On Thu, Oct 24, 2013 at 7:17 PM, Mike Tutkowski
>>>>>>>>> >> >>> <mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>>
>>>>>>>>> >> >>>> My guess is XenCenter gets info about stopped VMs from the
>>>>>>>>> XenServer
>>>>>>>>> >> >>>> hosts it logs in to. I don't think it maintains a DB like
>>>>>>>>> vCenter does.
>>>>>>>>> >> >>>>
>>>>>>>>> >> >>>>
>>>>>>>>> >> >>>> On Thu, Oct 24, 2013 at 7:15 PM, Mike Tutkowski
>>>>>>>>> >> >>>> <mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>>>
>>>>>>>>> >> >>>>> Actually, I don't know if XenCenter remembers the VMs per
>>>>>>>>> se or if
>>>>>>>>> >> >>>>> it gets that information from querying the XenServer
>>>>>>>>> hosts it has access to.
>>>>>>>>> >> >>>>>
>>>>>>>>> >> >>>>>
>>>>>>>>> >> >>>>> On Thu, Oct 24, 2013 at 7:14 PM, Mike Tutkowski
>>>>>>>>> >> >>>>> <mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>>>>
>>>>>>>>> >> >>>>>> No, it does allow you to do that. I wasn't sure what you
>>>>>>>>> meant by
>>>>>>>>> >> >>>>>> your comparison, but XenCenter does remember VMs as far
>>>>>>>>> as I know.
>>>>>>>>> >> >>>>>>
>>>>>>>>> >> >>>>>>
>>>>>>>>> >> >>>>>> On Thu, Oct 24, 2013 at 7:08 PM, Marcus Sorensen
>>>>>>>>> >> >>>>>> <shadowsor@gmail.com> wrote:
>>>>>>>>> >> >>>>>>>
>>>>>>>>> >> >>>>>>> Oh, xencenter doesn't remember VMS and allow you to
>>>>>>>>> start one if
>>>>>>>>> >> >>>>>>> the host it was on is down? I haven't played with it in
>>>>>>>>> a year but I thought
>>>>>>>>> >> >>>>>>> it synced with each xen server.
>>>>>>>>> >> >>>>>>>
>>>>>>>>> >> >>>>>>> On Oct 24, 2013 7:06 PM, "Mike Tutkowski"
>>>>>>>>> >> >>>>>>> <mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>>>>>>
>>>>>>>>> >> >>>>>>>> Well...XenCenter is "just" the GUI (like VI Client is
>>>>>>>>> for
>>>>>>>>> >> >>>>>>>> vSphere). As far as I know, XenServer has no
>>>>>>>>> equivalent to vCenter Server.
>>>>>>>>> >> >>>>>>>>
>>>>>>>>> >> >>>>>>>>
>>>>>>>>> >> >>>>>>>> On Thu, Oct 24, 2013 at 6:52 PM, Marcus Sorensen
>>>>>>>>> >> >>>>>>>> <shadowsor@gmail.com> wrote:
>>>>>>>>> >> >>>>>>>>>
>>>>>>>>> >> >>>>>>>>> That is probably true, but there is no xencenter or
>>>>>>>>> vsphere
>>>>>>>>> >> >>>>>>>>> equivalent for KVM, no central authority. Its
>>>>>>>>> cloudstack.
>>>>>>>>> >> >>>>>>>>>
>>>>>>>>> >> >>>>>>>>> On Oct 24, 2013 6:22 PM, "Mike Tutkowski"
>>>>>>>>> >> >>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>> OK, thanks for that info, Marcus...I was not aware
>>>>>>>>> that
>>>>>>>>> >> >>>>>>>>>> CloudStack treated VMs ephemerally with KVM.
>>>>>>>>> >> >>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>> I guess I should try to stop a VM on XenServer and
>>>>>>>>> ESX and see
>>>>>>>>> >> >>>>>>>>>> what happens. I was under the impression they
>>>>>>>>> remained accessible using
>>>>>>>>> >> >>>>>>>>>> XenCenter or VI Client, but perhaps I am wrong about
>>>>>>>>> that.
>>>>>>>>> >> >>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>> Since my KVM VM's root disk was on local storage, I
>>>>>>>>> expected it
>>>>>>>>> >> >>>>>>>>>> to remain accessible in VMM after I had stopped it
>>>>>>>>> via CS.
>>>>>>>>> >> >>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>> On Thu, Oct 24, 2013 at 6:16 PM, Marcus Sorensen
>>>>>>>>> >> >>>>>>>>>> <shadowsor@gmail.com> wrote:
>>>>>>>>> >> >>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>> Are you talking cloudstack VMS or your own?  If a
>>>>>>>>> vm is
>>>>>>>>> >> >>>>>>>>>>> 'created' it is ephemeral, the definition will
>>>>>>>>> disappear when stopped. This
>>>>>>>>> >> >>>>>>>>>>> is what cloudstack does so that a KVM host that
>>>>>>>>> crashes or loses power won't
>>>>>>>>> >> >>>>>>>>>>> remember and try to start VMS that were previously
>>>>>>>>> on it (they are likely
>>>>>>>>> >> >>>>>>>>>>> running elsewhere now). However, for your desktop
>>>>>>>>> and your own VMS you
>>>>>>>>> >> >>>>>>>>>>> usually 'define' VMS, which saves the XML to a file
>>>>>>>>> and leaves them
>>>>>>>>> >> >>>>>>>>>>> persistent. I use vmm occasionally, but usually
>>>>>>>>> virsh, the CLI version. Both
>>>>>>>>> >> >>>>>>>>>>> just talk to libvirt.
>>>>>>>>> >> >>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>> On Oct 24, 2013 6:08 PM, "Mike Tutkowski"
>>>>>>>>> >> >>>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>> Hey Marcus,
>>>>>>>>> >> >>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>> I assume you use Virtual Machine Manager with KVM?
>>>>>>>>> >> >>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>> I was wondering, is there a way when you stop a VM
>>>>>>>>> to have it
>>>>>>>>> >> >>>>>>>>>>>> not disappear from the GUI?
>>>>>>>>> >> >>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>> In XenCenter and VI Client, stopped VMs just show
>>>>>>>>> up with a
>>>>>>>>> >> >>>>>>>>>>>> different icon, but are still easy to interact
>>>>>>>>> with.
>>>>>>>>> >> >>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>> Thanks!
>>>>>>>>> >> >>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:46 PM, Mike Tutkowski
>>>>>>>>> >> >>>>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>> Also, the way I determined if the attach/detach
>>>>>>>>> worked was
>>>>>>>>> >> >>>>>>>>>>>>> to use fdisk -l and see if the device was present
>>>>>>>>> or not in the hypervisor
>>>>>>>>> >> >>>>>>>>>>>>> and VM instance.
>>>>>>>>> >> >>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:42 PM, Mike Tutkowski
>>>>>>>>> >> >>>>>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>> Here are some of the tests I ran on this code:
>>>>>>>>> >> >>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>> attach/detach/attach volume while VM is running:
>>>>>>>>> works
>>>>>>>>> >> >>>>>>>>>>>>>> volume attached while VM is running, then
>>>>>>>>> reboot: works
>>>>>>>>> >> >>>>>>>>>>>>>> volume attached while VM is running, then reset:
>>>>>>>>> works
>>>>>>>>> >> >>>>>>>>>>>>>> volume detached while VM is stopped, then start:
>>>>>>>>> works
>>>>>>>>> >> >>>>>>>>>>>>>> volume attached while VM is stopped, then start:
>>>>>>>>> works
>>>>>>>>> >> >>>>>>>>>>>>>> deleted VM with attached volume: works (volume
>>>>>>>>> goes into
>>>>>>>>> >> >>>>>>>>>>>>>> the attachable state after VM is expunged)
>>>>>>>>> >> >>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:40 PM, Mike Tutkowski
>>>>>>>>> >> >>>>>>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>> By the way, in case you're looking at the diff
>>>>>>>>> and
>>>>>>>>> >> >>>>>>>>>>>>>>> wondering why I took out a StopCommand check
>>>>>>>>> and call to execute in
>>>>>>>>> >> >>>>>>>>>>>>>>> LibvirtComputingResource, there were two of
>>>>>>>>> them.
>>>>>>>>> >> >>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>> -            } else if (cmd instanceof
>>>>>>>>> StopCommand) {
>>>>>>>>> >> >>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>> -                return execute((StopCommand)
>>>>>>>>> cmd);
>>>>>>>>> >> >>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:26 PM, Mike Tutkowski
>>>>>>>>> >> >>>>>>>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>> This is a newer link, Marcus:
>>>>>>>>> >> >>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>
>>>>>>>>> https://github.com/mike-tutkowski/incubator-cloudstack/commit/e84de7577ad38fea88d1492d4949672d1989889b
>>>>>>>>> >> >>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>> I just rebased on top of master today.
>>>>>>>>> >> >>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 3:46 PM, Mike Tutkowski
>>>>>>>>> >> >>>>>>>>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>> Hey Marcus,
>>>>>>>>> >> >>>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>> If you're interested in running the simulator
>>>>>>>>> against
>>>>>>>>> >> >>>>>>>>>>>>>>>>> your code + my code, I have it on GitHub here:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>
>>>>>>>>> https://github.com/mike-tutkowski/incubator-cloudstack/commit/776f3eb9dda45745f43e6765b026d34fbc6be072
>>>>>>>>> >> >>>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>> >> >>>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 11:06 PM, Mike
>>>>>>>>> Tutkowski
>>>>>>>>> >> >>>>>>>>>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>> I'm trying to attach my diff to
>>>>>>>>> >> >>>>>>>>>>>>>>>>>> https://reviews.apache.org/r/13865/, but I
>>>>>>>>> don't see the necessary buttons.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>> I wonder if I need to get edit access back
>>>>>>>>> again? We
>>>>>>>>> >> >>>>>>>>>>>>>>>>>> had trouble with the Wiki. Was this also
>>>>>>>>> impacted?
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 10:47 PM, Mike
>>>>>>>>> Tutkowski
>>>>>>>>> >> >>>>>>>>>>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> Sure, I can create a diff file and attach
>>>>>>>>> it to Review
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> Board.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 10:40 PM, Marcus
>>>>>>>>> Sorensen
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> <shadowsor@gmail.com> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> Sure. The majority of it only affects
>>>>>>>>> people who are
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> on your storage
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> anyway. Perhaps you can post a patch and I
>>>>>>>>> can run it
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> through the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> simulator to verify that the minor change
>>>>>>>>> to the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> existing code hasn't
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> broken the standard storages. I don't
>>>>>>>>> think it is
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> since I've
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> thoroughly tested the code I posted, but I
>>>>>>>>> know there
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> were some
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> additional changes.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 10:35 PM, Mike
>>>>>>>>> Tutkowski
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> > OK, Marcus, I made the change to detect
>>>>>>>>> my volumes
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> > and it seems to work just
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> > fine.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> > Perhaps another day of testing and we
>>>>>>>>> can check
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> > this code in. What do you
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> > think?
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> > On Wed, Oct 23, 2013 at 9:14 PM, Mike
>>>>>>>>> Tutkowski
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> > <mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> Thanks, Marcus...I hadn't read that
>>>>>>>>> note, but that
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> makes sense.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> Yes, that must be the root disk for the
>>>>>>>>> VM. I can
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> put in code, as you
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> recommend, to handle only my volumes.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> On Wed, Oct 23, 2013 at 5:37 PM, Marcus
>>>>>>>>> Sorensen
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> <shadowsor@gmail.com>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> It should be sending the path info for
>>>>>>>>> each disk
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> per the XML of the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> VM... so it will send all disks
>>>>>>>>> regardless of
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> whether or not your
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> adaptor manages that disk, and it's up
>>>>>>>>> to your
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> adaptor to ignore any
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> that aren't managed by it. There
>>>>>>>>> should be notes
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> to that effect in the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> code near the disconnectPhysicalDisk
>>>>>>>>> interface in
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> StorageAdaptor:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>     // given local path to file/device
>>>>>>>>> (per
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> Libvirt XML), 1) check
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> that device is
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>     // handled by your adaptor, return
>>>>>>>>> false if
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> not. 2) clean up
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> device, return true
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>     public boolean
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> disconnectPhysicalDiskByPath(String
>>>>>>>>> localPath);
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> Since we only have XML disk
>>>>>>>>> definitions when we
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> stop or migrate a VM,
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> we have to try all adaptors against
>>>>>>>>> all defined
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> disks. So in your
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> disconnectPhysicalDisk you might do
>>>>>>>>> something
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> like check that the path
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> starts with '/dev/disk/by-path' and
>>>>>>>>> contains
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> 'iscs-iqn' (maybe there's
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> some way that's more robust like
>>>>>>>>> checking the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> full path against a lun
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> listing or something). If it doesn't
>>>>>>>>> match, then
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> your
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> disconnectPhysicalDisk just does
>>>>>>>>> nothing.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> I assume this is a root disk or some
>>>>>>>>> other local
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> storage disk. If it's
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> not, then your VM XML is messed up
>>>>>>>>> somehow.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> On Wed, Oct 23, 2013 at 5:01 PM, Mike
>>>>>>>>> Tutkowski
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> <mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > I found the problem.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > disconnectPhysicalDiskByPath is
>>>>>>>>> being passed in
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > (in my situation) the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > following:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>>>>> /var/lib/libvirt/images/9887d511-8dc7-4cb4-96f9-01230fe4bbb6
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > Due to the name of the method, my
>>>>>>>>> code was
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > expecting data such as the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > following:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>>>>> /dev/disk/by-path/ip-192.168.233.10:3260-iscsi-iqn.2012-03.com.solidfire:volume1-lun-0
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > Was it intentional to send the data
>>>>>>>>> into this
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > method in the current
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > way?
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > On Wed, Oct 23, 2013 at 1:57 PM,
>>>>>>>>> Mike Tutkowski
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > <mike.tutkowski@solidfire.com>
>>>>>>>>> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> You know, I forgot we supposed to
>>>>>>>>> be doing
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> that! :) Multi-tasking too
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> much
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> today, I guess.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> Anyways, it must not be working
>>>>>>>>> because I
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> still had a hypervisor
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> connection after I shut down the VM.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> Let me investigate.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> On Wed, Oct 23, 2013 at 1:48 PM,
>>>>>>>>> Marcus
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> Sorensen <shadowsor@gmail.com>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> Are we not disconnecting when we
>>>>>>>>> stop the vm?
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> There's a method for
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> it, we
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> should be.
>>>>>>>>> disconnectPhysicalDiskViaVmSpec
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> On Oct 23, 2013 1:28 PM, "Mike
>>>>>>>>> Tutkowski"
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> <mike.tutkowski@solidfire.com>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> I see one problem for us now,
>>>>>>>>> Marcus.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You have a running VM that you
>>>>>>>>> attach a
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> volume to.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You stop the VM.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You detach the volume.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You start up the VM.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> The VM will not be connected to
>>>>>>>>> the volume
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> (which is good), but the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> hypervisor will still be
>>>>>>>>> connected to the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> volume.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> It would be great if we actually
>>>>>>>>> sent a
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> command to the last host ID
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> of
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> the stopped VM when detaching a
>>>>>>>>> volume (to
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> have the hypervisor
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> disconnect
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> from the volume).
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> What do you think about that?
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> On Wed, Oct 23, 2013 at 1:15 PM,
>>>>>>>>> Mike
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> Tutkowski
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> <mike.tutkowski@solidfire.com>
>>>>>>>>> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> OK, whatever way you prefer
>>>>>>>>> then, Marcus
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> (createVdb first or
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> second).
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> If I leave createVdb first and
>>>>>>>>> return 0, it
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> does seem to work.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> On Wed, Oct 23, 2013 at 11:13
>>>>>>>>> AM, Marcus
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> Sorensen
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> <shadowsor@gmail.com>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> I think we could flip-flop
>>>>>>>>> these two lines
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> if necessary:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>             createVbd(conn,
>>>>>>>>> vmSpec,
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> vmName, vm);
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>>>>>> _storagePoolMgr.connectPhysicalDisksViaVmSpec(vmSpec);
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> I haven't actually tried it
>>>>>>>>> though. But in
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> general I don't see the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> Libvirt DiskDef using size at
>>>>>>>>> all, which
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> is what createVbd does
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> (creates XML definitions for
>>>>>>>>> disks to
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> attach to the VM
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> definition). It
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> just takes the device at it's
>>>>>>>>> native
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> advertised size when it
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> actually
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> goes to use it.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> On Wed, Oct 23, 2013 at 10:52
>>>>>>>>> AM, Mike
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> Tutkowski
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> <mike.tutkowski@solidfire.com>
>>>>>>>>> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > Little problem that I wanted
>>>>>>>>> to get your
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > take on, Marcus.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > When a VM is being started,
>>>>>>>>> we call
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > createVdb before calling
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > connectPhysicalDisksViaVmSpec.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > The problem is that createVdb
>>>>>>>>> calls
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > getPhysicalDisk and my
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > volume
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > has not
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > yet been connected because
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > connectPhysicalDisksViaVmSpec
>>>>>>>>> has not
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > yet
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > been
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > called.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > When I try to read up the
>>>>>>>>> size of the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > disk to populate a
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > PhysicalDisk, I get
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > an error, of course, because
>>>>>>>>> the path
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > does not yet exist.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > I could populate a 0 for the
>>>>>>>>> size of the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > physical disk and then
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > next
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > time getPhysicalDisk is
>>>>>>>>> called, it
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > should be filled in with a
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > proper
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > size.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > Do you see a problem with
>>>>>>>>> that approach?
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > On Tue, Oct 22, 2013 at 6:40
>>>>>>>>> PM, Marcus
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > Sorensen
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > <shadowsor@gmail.com>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> That's right. All should be
>>>>>>>>> well.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> On Oct 22, 2013 6:03 PM,
>>>>>>>>> "Mike
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> Tutkowski"
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> <
>>>>>>>>> mike.tutkowski@solidfire.com>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> Looks like we disconnect
>>>>>>>>> physical
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> disks when the VM is
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> stopped.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> I didn't see that before.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> I suppose that means the
>>>>>>>>> disks are
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> physically disconnected
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> when
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> the VM is
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> stopped, but the CloudStack
>>>>>>>>> DB still
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> has the VM associated
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> with
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> the disks
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> for the next time the VM
>>>>>>>>> may be
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> started up (unless someone
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> does a
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> disconnect
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> while the VM is in the
>>>>>>>>> Stopped State).
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> On Tue, Oct 22, 2013 at
>>>>>>>>> 4:19 PM, Mike
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> Tutkowski
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> <
>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Hey Marcus,
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Quick question for you
>>>>>>>>> related to
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> attaching/detaching volumes
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> when the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM is in the Stopped State.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> If I detach a volume from
>>>>>>>>> a VM that
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> is in the Stopped State,
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> DB
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> seems to get updated, but
>>>>>>>>> I don't see
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> a command going to the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> KVM
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> hypervisor
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> that leads to the removal
>>>>>>>>> of the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> iSCSI target.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> It seems the iSCSI target
>>>>>>>>> is only
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> removed the next time the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM is
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> started.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Do you know if this is
>>>>>>>>> true?
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> If it is, I'm concerned
>>>>>>>>> that the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> volume could be attached to
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> another VM
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> before the Stopped VM is
>>>>>>>>> re-started
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> and when the Stopped VM
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> gets
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> restarted
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> that it would disconnect
>>>>>>>>> the iSCSI
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> volume from underneath the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> that now
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> has the volume attached.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> I still want to perform
>>>>>>>>> some tests on
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> this, but am first
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> trying
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> to get a
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM to start after I've
>>>>>>>>> attached a
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> volume to it when it was in
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Stopped
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> State.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Thanks,
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Mike
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> On Mon, Oct 21, 2013 at
>>>>>>>>> 10:57 PM,
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Mike Tutkowski
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> <
>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Thanks for that info,
>>>>>>>>> Marcus.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> By the way, I wanted to
>>>>>>>>> see if I
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> could attach my volume to
>>>>>>>>> a
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> VM
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> in the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Stopped State.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> The attach logic didn't
>>>>>>>>> trigger any
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> exceptions; however,
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> when I
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> started
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> the VM, I received an
>>>>>>>>> Insufficient
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Capacity exception.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> If I detach the volume
>>>>>>>>> and then
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> start the VM, the VM
>>>>>>>>> starts
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> just
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> fine.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> I noticed a problem here
>>>>>>>>> (in
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> StoragePoolHostDaoImpl):
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>     @Override
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>     public
>>>>>>>>> StoragePoolHostVO
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> findByPoolHost(long
>>>>>>>>> poolId,
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> long
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> hostId) {
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> SearchCriteria<StoragePoolHostVO> sc =
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> PoolHostSearch.create();
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> sc.setParameters("pool_id",
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> poolId);
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> sc.setParameters("host_id",
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> hostId);
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>         return
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> findOneIncludingRemovedBy(sc);
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>     }
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> The
>>>>>>>>> findOneIncludingRemovedBy method
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> returns null (the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> poolId is
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> my
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> storage pool's ID and the
>>>>>>>>> hostId is
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> the expected host ID).
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> I'm not sure what this
>>>>>>>>> method is
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> trying to do.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> I looked in the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> storage_pool_host_ref
>>>>>>>>> table (is that the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> correct
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> table?) and it only has
>>>>>>>>> one row,
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> which maps the local
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> storage
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> pool of the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> KVM host to the KVM host
>>>>>>>>> (which
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> explains why no match is
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> found
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> for my
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> situation).
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Do you understand what
>>>>>>>>> this logic is
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> trying to do?
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Thanks!
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> On Mon, Oct 21, 2013 at
>>>>>>>>> 8:08 PM,
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Marcus Sorensen
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> <shadowsor@gmail.com>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> Do you have the
>>>>>>>>> capability to clone
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the root disk? Normally
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> template is installed to
>>>>>>>>> primary,
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> and then cloned for each
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> root
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> disk.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> In some cases (such as
>>>>>>>>> CLVM), this
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> isn't efficient and so
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> template
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> is copied fresh to
>>>>>>>>> populate each
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> root disk.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> I'm actually not 100%
>>>>>>>>> sure how this
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> works in the new code.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> It
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> used to
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> be handled by
>>>>>>>>> copyPhysicalDisk in
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the storage adaptor,
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> called
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> by
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>>>>>> copyTemplateToPrimaryStorage, which
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> runs on the agent. It
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> would
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> pass
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> template/secondary
>>>>>>>>> storage info,
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> and the destination
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> volume/primary
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> storage info, and
>>>>>>>>> copyPhysicalDisk
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> would do the work of
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> installing the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> image to the
>>>>>>>>> destination.  Then
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> subsequent root disks
>>>>>>>>> would
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> be
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> cloned
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> in CreateCommand by
>>>>>>>>> calling
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> createDiskFromTemplate.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> In master it looks like
>>>>>>>>> this was
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> moved to
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> KVMStorageProcessor
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>>>>>> 'cloneVolumeFromBaseTemplate',
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> although I think this
>>>>>>>>> just
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> takes
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> over
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> as default, and there's
>>>>>>>>> something
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> in your storage driver
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> that
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> should
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> be capable of cloning
>>>>>>>>> templates on
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the mgmt server side.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> I'm
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> less sure
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> about how the template
>>>>>>>>> gets to
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> primary storage in the
>>>>>>>>> first
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> place, I
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> assume
>>>>>>>>> copyTemplateToPrimaryStorage
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> in KVMStorageProcessor
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> calling
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> copyPhysicalDisk in your
>>>>>>>>> adaptor.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> It's a bit tough for me
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> to
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> tell
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> since our earlier
>>>>>>>>> storage adaptor
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> did everything on the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> host it
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> mostly
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> just worked with the
>>>>>>>>> default stuff.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> On Mon, Oct 21, 2013 at
>>>>>>>>> 4:49 PM,
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> Mike Tutkowski
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> <
>>>>>>>>> mike.tutkowski@solidfire.com>
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> wrote:
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > Hey Marcus,
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > So...now that this
>>>>>>>>> works well for
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > data disks, I was
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > wondering
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > what
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > might be
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > involved in getting
>>>>>>>>> this process
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > to work for root disks.
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > Can you point me in
>>>>>>>>> the right
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > direction as far as
>>>>>>>>> what
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > gets
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > invoked
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > when a
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > VM is being created on
>>>>>>>>> KVM (so
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > that its root disk can
>>>>>>>>> be
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > created and
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > the
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > necessary template
>>>>>>>>> laid down or
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > ISO installed)?
>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>>>>>>
>>>>>>>> ...
>>>>
>>>>
>>>
>>>
>>> --
>>> *Mike Tutkowski*
>>>  *Senior CloudStack Developer, SolidFire Inc.*
>>> e: mike.tutkowski@solidfire.com
>>> o: 303.746.7302
>>> Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>
>>> *™*
>>>
>>
>>
>>
>> --
>> *Mike Tutkowski*
>>  *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkowski@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>
>> *™*
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>
> *™*
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message